Yea, but, this is Rust. How is a moving GC supposed to handle an untagged union? Or a person who uses the now-stable provenance api to read/write pointer bits to/from disk.

A Gc<T> that can't give you a pointer inside seems almost unusable in the context of Rust. Pointers are not a narrow use case; references are pointers.

Rust APIs are largely built around references. If you were to put a Vec<T> (dynamic array) into a pointerless Gc<T>, you would be almost entirely unable to access its contents. The only way to access it would be swap it with an empty Vec, access it, then swap it back a-la Cell. You wouldn't even be able to clone the Vec without storing a dummy version in its place during the call.

https://doc.rust-lang.org/stable/std/cell/struct.Cell.html#m...

You miss the point: I'm referring to cases where you pass pointers from one language into another. In that case, because GC is opt-in, it's the wrong approach for managing whatever you're passing into the non-Rust language.

In your case, do you need to get a pointer to a GC<T> and use it within Rust? I haven't worked with Rust at that level yet, so perhaps I'm ignorant of a more common use case.

> those only apply to arrays of primitives

I guess you've not written much python, or just not used any custom types in lists if you have.

    class Thing:
        def __init__(self, a, b):
            self.a = a; self.b = b
        def __eq__(me, them):
            return me.a == them.a and me.b == them.b
    >>>[1, 2, Thing(6, "Hi")] == [1, 2, Thing(6, "Hi")]
    True
    >>>[1, 2, Thing(6, "Hi")] == [1, 2, Thing(6, "Hello")]
    False

In this case, the builtins are syntax, namely the `==` operator. There's a uniform syntax for comparing two objects for equality.

Sure, the language has a mechanism for overriding the equality operator for classes, just like Java has .equals(), but the code is overriding the builtin algorithm. The case of comparing mixed type arrays is not a usual case and seems contrived. In JS, you could do the same by extending Array and using that, or implementing a custom .equals() for your objects. I suppose Python is a bit more functional in that respect.

Are you blind or using Orca to interact with your computer? If the answer is no, then your recent experience with Debian is not particularly relevant to what the article is talking about, since you obviously wouldn't have run in to any of the issues discussed.

What about this: https://godbolt.org/z/xP9xG3Ee3

Here the compiler "register allocates" i for some reads but not for others.

i gets stack allocated, but some uses of it act as though they were register allocated.

I'm not sure quite what you're asking for exactly, given the link is for clang trunk and doesn't have the modifications discussed in TFA, and I don't dispute that clang does UB-based reasoning at -O3. But, I will argue that the assembly shown can be accomplished without resorting to what I call "reasoning about UB", and within a flat memory model, supporting the claim that these sacrifices are often not necessary. I'm going to draw a distinction between stack memory being "private" in the sense that only the compiler is allowed to alter it, and "public" where the address can be written to by something else and the compiler needs to handle that. Local variables at first are tracked privately. After the address of a variable is taken with &x, or at the point in time when an array variable is indexed, the associated memory is public. Conceptually, the use of private memory can be indirect; the compiler could encode/decode a stack variable x as (x XOR 0xDEADBEEF) on the stack and it would be fine (but the compiler does the simple thing in practice, naturally). Note that this notion of "private"/"public" stack memory is a property of addresses, not the provenance of the accessing pointers, and so is fully compatible with a flat memory model. The compiler's ability to use private memory isn't a case of "reasoning around UB" in a meaningful sense -- otherwise you could just as well argue that returning from a function call is "reasoning about UB", because the the return address can't be clobbered.

In your provided snippet, the correctness argument for the assembly in a non-UB-reasoning universe goes like this: at first, i is stored privately on the stack with value zero, and so as an optimization we can assume that value is still zero without rereading. Only later, when &i is taken, is that memory made public and the compiler has to worry about something altering it. In actual execution, the problem is that the write function alters compiler-private memory (and note again, that being private is a property of the underlying address, not the fact that it's accessed via an out-of-bounds array indexing), and this is UB and so the program breaks. But, the compiler didn't need to make _assumptions_ around UB.

assoc-in reminds me a lot of lenses in Haskell. I figure you could probably implement something like it using them. This is what I came up with:

  import Control.Lens
  baseLens --> nextIndex = baseLens . ix nextIndex
  assocIn structure keyLens newValue = set keyLens newValue structure

It works like so:

  setTo256 structure = assocIn structure (ix 0 --> 0 --> 0) 256
  -- setTo256 [[[1]], [[2]]] returns [[[256]], [[2]]]

All it takes for something to be replaced is something that does the job better. You can only really apply your definition in hindsight, after something has stood the test of time. You can't tell the difference between sails and wheels until after the rise of the steam engine.

The first line is already UB. `assume_init` requires the contents to be initialized, hence the name.

Mmm, I went back and read the docs for MaybeUnit more carefully and that's a good point.

It may be better to just leave the assignment off the declaration. If the variable is read before it's initialized to something, we'll get a Rust compilation error, forcing programmer intervention. Detecting actual bugs that would result in memory errors and forcing them to be resolved is very much in the spirit of Rust. TRACTOR may aspire to gift C programs with memory safety for free, but it won't always be possible.

Of course if TRACTOR can determine through static analysis that the unitialized read can't cause problems, it might emit different code.