Prototype of Ownership/Borrowing System for D
Doc Andrew
x at x.com
Thu Nov 21 03:47:21 UTC 2019
On Wednesday, 20 November 2019 at 22:15:18 UTC, Walter Bright
wrote:
>
> 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
short period
of time:
T* foo();
T* p = foo(); //Undefined state
if(p)
{
//We opened Schrodinger's pointer and know it's not null
anymore.
}
else
{
//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
mailing list