null [re: spec#]

[Andrei Alexandrescu]

On 11/7/10 4:21 PM, bearophile wrote:
> 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.

The only change needed is constructor flow to make sure types with 
@disable'd constructors are always properly initialized. Array 
construction can be supported with a library function.

>> 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).

Such work is not new to Spec# (there are papers that introduce 
non-nullables to Java, with which I'm very familiar). I think simpler 
solutions are available by restricting constructors appropriately.

> 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...

If there are design holes those need to be known. There is awareness and 
institutional memory (via bugzilla) about bugs in the implementation.


Andrei