null [re: spec#]

[bearophile]

Andrei Alexandrescu:

> And what was exactly the claim that was wrong?

That there is no need of compiler & syntax support to implement "good enough" nonnullable reference types in D.


> What's a relative semantics?

- The limited form of typestate change, as shown in the original Spec# paper I've shown; I have explained this five times in recent posts, if you want I may explain again.
- Some good solution to the problem of initializing a collection of nonnullable references, a possible solution is explained in the oiriginal Spec# paper I have shown. This too uses a limited form of typestate. But other solutions may be invented that don't require typestates.
- Some good solution to the problem of initializing struct/class fields, as explained in the second paper I have linked, regarding "delayed types".

Most of that semantics can't be expressed in D, so you need compiler support (and syntax support, but syntax here is very limited, you just need @ ? @notDelayed and something like a "done" for arrays/collections of nonnull references. Syntax is the simplest part of this design).

In the end seeing the amount of holes left in the design of the D module system and immutables, this nonnull design may be too much hard for D, most people here don't even see 1/2 of the problems needed to implement nonnullables well enough. So maybe we are just wasting time here. D newsgroup probably needs threads about possible ways to fix/finish the features D2 already has...

Bye,
bearophile