Steven Schveighoffer: > Build the non-null requirement into the function signature (note, the > requirement is optional, it's still possible to use null references if you > want). > > Pros: Easy to implement, Compile-time error, hard to "work around" by > putting a dummy value, sometimes no performance hit, most times very > little performance hit, allows solution 1 and 2 if you want, runtime > errors occur AT THE POINT things went wrong not later. > Cons: Non-zero performance hit (you have to check for null sometimes > before assignment!)
To implement it well (and I think it has to be implemented well) it's not so easy to implement. You have to face the problem I've discussed about about multiple object initializations inside various ifs. Also see what downs and I have said regarding arrays of nonnullables. Among the cons you also have to consider that there's a little more complexity in the language (two different kinds of references, and such things must also be explained in the docs and understood by novice D programmers. It's not a common feature, so they have to learn it). Another thing to add to the cons is that every layer of compile-time constraints you add to a language they also add a little amount of rigidity that has a cost (because you have to add ? and you sometimes may need casts to break such rigidity). Dynamic languages show that constraints have a cost. Bye, bearophile
