Smart pointers instead of GC?

[woh]

unique is best, should be default, down with GC!!


Tuesday, 4 February 2014 at 14:19:36 UTC, Frank Bauer wrote:
> On Tuesday, 4 February 2014 at 13:18:51 UTC, Dicebot wrote:
>> For me perfect solution would have been to use an allocator 
>> concept as language basis instead and let you chose any 
>> conformant allocator for built-in language features. With both 
>> GC and ARC available in Phobos / druntime.
>
> That is exactly what Rust did succsessfully.
>
> http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/
>
> got pulled.
>
> They deprecated the @ pointer, which is a managed poiter 
> equivalent to what D's 'new' produces, to a library solution.
>
> They now have basically only ~T and &T left in the language. ~T 
> being an owned pointer that frees at the end of its scope and 
> &T, a borrowed pointer (or reference, but *not* RC) with no 
> direct effect on memory management.
>
> There is Rc<T> and Gc<T> in the library for those who wish to 
> use them.
>
> To quote from the above link:
>
>>>
> Programmers don’t know which to use, since some operations are 
> available with ~ and some operations are available with @. 
> Actually, we were confused on this point for a long time as 
> well—it wasn’t clear whether ~ or @ would become dominant. We 
> debated for a long time which to present first, ~ or @. 
> However, as the language and community evolved, and coding 
> standards became more settled, a clear winner emerged: the 
> owning pointer ~. In practice, the rule has been that 
> programmers should use ~ to allocate in all circumstances 
> except when they have no way of knowing precisely when the 
> object in question should be freed.
> <<
>
> This is what happens if you give users choice.
>
> One of Rust's priorities is to have a runtime footprint as 
> small as possible. I would give priority to not break existing 
> D code. So keep GC'd 'new' in the language (the runtime will 
> never get as small as Rust's; don't care) and see if it is 
> possible to add owned and ARC pointers from there.