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