(non)nullable types
Christopher Wright
dhasenan at gmail.com
Tue Feb 17 15:17:55 PST 2009
Sergey Gromov wrote:
> Mon, 16 Feb 2009 13:26:29 +1100, Daniel Keep wrote:
>
>> To clarify: I am, and always have been, in full support of non-nullable
>> types, preferably by default. What I object to specifically in this
>> case is the requirement to always check that a nullable value is not
>> null every time it is used.
>
> Hmm, I think I've got your point. The nullable types should work
> exactly as they work now, with the same consequences. You don't need to
> check for null to dereference, and you crash if you dereference null.
> The non-nullable types are a separate territory. Again, you don't need
> to check for null to dereference, and you never crash because there is
> never null. You need an explicit run-time check to move from null to
> non-null territory, but that's all you need, and only when you really
> want it.
>
> I think it's my favorite design so far.
One possible change: implicit casting with an assertion that the
nullable value is not null. I'm not sure whether this is a good idea. On
the one hand, it's easier for the programmer to use nullable types in
that case; on the other, it encourages people not to have error handling.
I favor implicit casting, for now. It shouldn't be difficult to try it
both ways.
More information about the Digitalmars-d
mailing list