(non)nullable types

Nick Sabalausky a at a.a
Fri Feb 13 02:51:14 PST 2009


"Brian" <digitalmars at brianguertin.com> wrote in message 
news:gn3dfn$2lp3$1 at digitalmars.com...
> On Thu, 12 Feb 2009 08:41:54 -0500, Christopher Wright wrote:
>> Brian mentioned having to check if the variable is null before using it.
>> This would not be easy to implement, and it might be a bit hard to use.
>> Again, I'd have to see it in use.
>
> after a bit of thought i dont think theres much/any benefit of forcing a
> check. if nonnullable was the default then using a nullable version is
> expected to be unusual and potentially unsafe.

I don't see much of a point in not forcing a check. I can't think of a case 
where it would be useful or desirable to use a nullable type without first 
checking for null (except for passing it to a func that takes a nullable as 
a param or assigning it to another nullable of the same type, but presumably 
the check wouldn't be required in those cases). So it may as well be forced 
(when dereferencing and converting to non-nullable), since you'd never 
really want/need to do otherwise.

Even if the compiler simplified the process by only accepting the exact 
pattern of "if(x !is null)...", and didn't do any fancier analysis than 
that, I would still consider that accptable since, as you said, it would be 
a non-standard use.  So therefore, a (very) minor inconvenience like that 
would be acceptable, particularly considering it would essentially guarantee 
no null reference errors (aside from manual use of pointers, of course). 





More information about the Digitalmars-d mailing list