3 ms·

I'm curious about the reasoning behind the removal and what it means to Rust. Do you have any links on that? I tried looking on both Github and Discourse but co

• steveklabnik 12y ago
  Historically, @T, which is now Gc<T>, was assumed to be the 'default' pointer type. Like, from a conventions standpoint. And it was used all over the place. As we wrote more and more Rust, it became clear that unique ownership (~T, now Box<T>) was just as useful, faster, and better. Remember, this type basically compiles down to a regular pointer, with compiler inserted malloc/free. So you can imagine how much less that is compared to a refcount + cycle detection. So, Gc<T> was never really improved, and it's usage in the compiler itself was less and less. The last place it was used was in the AST, and so syntax extensions used it, but we didn't recommend it for anything else. Now, this past week, a contributor managed to re-write the AST to not use Gc<T>, so even than is gone. Or will be soon, I forget if it's passed CI so far. But anyway, now that it's gone, it will probably be simply removed, though that decision hasn't been made yet. Basically, what it means is that affine types are awesome.
  • ldng 12y ago
    So, so that mean that Gc will probably be phased out of the standard library. Now I come to think of it, since Rust knows the lifetime of most (all ?) the memory, would it be thinkable that the compiler also optimise memory mapping/fragmentation ? Or would that interfere with Dynamically Sized Types ? I feel I really out to dig deeper into Rust once it's a bit more stable.