(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