Opportunities for D

via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 9 06:06:05 PDT 2014


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


More information about the Digitalmars-d mailing list