On 27/09/2009 17:51, bearophile wrote:
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.
I don't accept this argument about nested if statements. D has a
procedural "if" statement. Of course it doesn't mesh together with
non-nullable references, you're trying to fit a square peg in a round hole.
the solution is to write a more functional style code. if D ever
implements true tuples that would be a perfect use case for them.
(T1 t1, T2 t2) = init();
t1.foo;
t2.bar;
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).
that's true. Not only this needs to be taught and pointed out to newbies
it should also be encouraged as the D way so that it will be used by
default.
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
