Prototype of Ownership/Borrowing System for D

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Thu Nov 21 10:37:41 UTC 2019


On Wednesday, 20 November 2019 at 22:15:18 UTC, Walter Bright 
wrote:
> 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.

If you're going to go with introducing new meanings like that, 
why not `&T` for the non-null pointer (to match Rust usage and 
the implicit comparison with taking the address of a stack 
variable)?

That would make it easier to introduce non-null pointers as 
opt-in without breaking existing code, and avoid any unintuitive 
differences with C APIs.

[By the way, isn't my bikeshed a lovely colour this season? :-)]

> Something like this is orthogonal to what @live is trying to 
> do, so I put it on the shelf for the time being.

Sure, it makes sense to split the data flow analysis from the 
question of how any given pointer has its value set.

That said, it intuitively feels like a non-null pointer type 
might want to be implicitly @live.  One could avoid imposing 
that, but it's hard to think of a situation where on would want 
the one, without the other.

The one thing that Rust does with its references, which I find a 
little bit _too_ limiting, is the "single mutable reference" 
constraint.  They do this by default in order to avoid various 
multithreading failure cases, but it blocks some of the easy 
design options one could use in single-threaded code.

_As a default_ that probably makes sense, but it would be good to 
have an opt-out for code designs that are not going to have those 
failure cases.


More information about the Digitalmars-d mailing list