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
