Prototype of Ownership/Borrowing System for D
x at x.com
Thu Nov 21 03:47:21 UTC 2019
On Wednesday, 20 November 2019 at 22:15:18 UTC, Walter Bright
> I originally was going to add null to the data flow analysis.
> But I realized it would be rather useless:
> T* foo();
> T* p = foo(); // is p null or not?
> Very quickly, the flow analysis would drop into "dunno if it is
> null or not" so it just won't be worth much.
You might only have to maintain this "undefined state" for a
T* p = foo(); //Undefined state
//We opened Schrodinger's pointer and know it's not null
//We know it's null here.
//Back to undefined state - we shouldn't deref p out here.
And honestly, knowing whether a pointer is in an undefined state
is still a very
useful piece of information that the flow analysis would provide.
Dereferencing a pointer of unknown provenance should be an error
in @live code,
no different than null.
> In order to make non-null checking actually work, the language
> semantics would likely need to change to make:
> T* a non-null pointer
> T?* an optionally null pointer
> or something like that. Two different pointer types would need
> to exist.
Maybe. As an alternative to that syntax, Consider a pointer with
a "notnull" attribute (storage class?) and a corresponding
"notnull" function attribute for the return type.
I'd expect runtime checks to be inserted in debug mode for the
function return and removed in release mode.
> Something like this is orthogonal to what @live is trying to
> do, so I put it on the shelf for the time being.
It's orthogonal, but very useful for correctness. I'm anxious to
see what comes of it...
...but hopefully not with ?*s scattered everywhere :)
More information about the Digitalmars-d