On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
3. 'ref' means 'borrowed', to use Rust's terminology
We're almost there with this. This means better escape
analysis, too.
IMO this is not good, because it should be applicable for
pointers, classes and slices, too (and structs containing any of
them, of course). If you use `ref` with these, an extra layer of
indirection is introduced, which also changes the semantics, e.g.
for non-const pointers the original pointer can suddenly be
overwritten. `scope` is much better suited for borrowing, because
it's orthogonal to `ref`.
1. Ref Counting
I believe that ARC is a pipe dream for D, as we've discussed
extensively here. But a ref counted object should work, and
would be very attractive, much like C++'s shared_ptr<T>.
2. Unique References
unique_ptr<T> is another big success for C++. 2.066 has already
made big strides in inferring uniqueness of expressions, but it
doesn't go so far as creating a Unique!T type.
std.type.Unique needs to be fleshed out, or a different type
created (`Owned`?). The current `Unique` accepts only pointers
and classes, but should really accept anything, as with
borrowing. Desirable features include:
* explicit or implicit move-semantics
* a way to remove uniqueness (e.g. after sending a value to a
different thread, it no longer needs to be Unique)
* compiler support for verifying that the value it's constructed
from _is_ actually unique
* deterministic destruction
* allocator support (because of the previous point)
* usable inside aggregates
* applicable to any type; a move overwrites the rhs with the
type's init value
Borrowing can elegantly solve many of the problems with Unique
and RC:
* Unique and RefCounted should be implicitly borrowable
(opBorrow?)
* library routines pervasively take their inputs as `scope`; no
need to provide different overloads for Unique, RefCounted,
normal values, or even user-implemented wrappers => abstracts
away the implementation details while retaining safety
