On 27/09/2009 05:45, Michel Fortin wrote:
On 2009-09-26 23:28:30 -0400, Michel Fortin <michel.for...@michelf.com>
said:
On 2009-09-26 22:07:00 -0400, Walter Bright
<newshou...@digitalmars.com> said:
[...] The facilities in D enable one to construct a non-nullable
type, and they are appropriate for many designs. I just don't see
them as a replacement for *all* reference types.
As far as I understand this thread, no one here is arguing that
non-nullable references/pointers should replace *all*
reference/pointer types. The argument made is that non-nullable should
be the default and nullable can be specified explicitly any time you
need it.
So if you need a reference you use "Object" as the type, and if you
want that reference to be nullable you write "Object?". The static
analysis can then assert that your code properly check for null prior
dereferencing a nullable type and issues a compilation error if not.
I just want to add: some people here are suggesting the compiler adds
code to check for null and throw exceptions... I believe like you that
this is the wrong approach because, like you said, it makes people add
dummy try/catch statements to ignore the error. What you want a
prorammer to do is check for null and properly handle the situation
before the error occurs, and this is exactly what the static analysis
approach I suggest forces.
Take this example where "a" is non-nullable and "b" is nullable:
string test(Object a, Object? b)
{
auto x = a.toString();
auto y = b.toString();
return x ~ y;
}
This should result in a compiler error on line 4 with a message telling
you that "b" needs to be checked for null prior use. The programmer must
then fix his error with an if (or some other control structure), like this:
string test(Object a, Object? b)
{
audo result = a.toString();
if (b)
result ~= b.toString();
return result;
}
And now the compiler will let it pass. This is what I'd like to see.
What do you think?
I'm not totally against throwing exceptions in some cases, but the above
approach would be much more useful. Unfortunatly, throwing exceptions it
the best you can do with a library type approach.
If you refer to my posts than I want to clarify:
I fully agree with you that in the above this can and should be
compile-time checked. This is a stricter approach and might seem
annoying to some programmers but is far safer.
Using non-null references by default will also restrict writing these
checks to only the places where it is actually needed.
In my posts I was simply answering Walter's claim.
Walter was saying that returning null is a valid and in fact better way
to indicate errors instead of returning some "default" value which will
cause the program to generate bad output.
My response to that was that if there's an error, the function should
instead throw an exception which provides more information and better
error handling.
null is a bad way to indicate errors precisely because of the point you
make - the compiler does not enforce the programmer to explicitly handle
the null case unlike the Option type in FP languages.
