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.
