(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