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