Prototype of Ownership/Borrowing System for D
SimonN
eiderdaus at gmail.com
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
annotation.
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