Smart pointers instead of GC?

[Frank Bauer]

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.