Prototype of Ownership/Borrowing System for D

SimonN eiderdaus at
Thu Nov 21 06:28:49 UTC 2019

On Thursday, 21 November 2019 at 03:47:21 UTC, Doc Andrew wrote:
>>    T*    a non-null pointer
>>    T?*   an optionally null pointer

Yes, optional pointers would be amazing, even though it breaks 
the syntax in most existing modules that uses pointers.

> alternative to that syntax, Consider a pointer with a "notnull" 
> attribute (storage class?) and a corresponding "notnull" 
> function attribute for the return type.

Ideally, the non-nullable pointer is the default, and the 
nullable pointer should be the oddball that requires explicit 

Thus the main benefit of the "notnull" attribute would be 
preserving existing D, certainly a huge benefit.

Reason: I'd estimate that 80% to 95% of all pointer code can be 
written with non-nullable pointers. No proof, only a hunch. Many 
functions already return non-null than maybe-null, the type 
system merely doesn't know it yet. Even if we return a null 
pointer, then our caller, on receiving the maybe-null pointer 
from us, tends to immediately check, thus immediately convert to 
non-nullable, or else return early.

Whenever the common case requires annotation, we foster 
annotation salad:

     int notnull* foo() const @pure @safe nothrow @nogc

With class references, non-nullability is even more common than 
with pointers. Typically, null class references appear only as 
member variables during construction of another class:

     class A { /* ... */ }
     class B {
         A a;
         this() {
             /* here is the only time that a is ever null */
             a = new A();

> It's orthogonal, but very useful for correctness.

Yes, it's entirely orthogonal. :-)

@live is conceptually different enough from non-nullability, it 
feels best to solve them separately. @live feels more like @safe 
instead, and even those turned out independent.

Exciting topic, hard to fit onto existing D codebases.

-- Simon

More information about the Digitalmars-d mailing list