(non)nullable types

[Christopher Wright]

Nick Sabalausky wrote:
> "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). 

The primary use case would be:
nullable T y = something;
non_nullable T x;
if (y) x = non_nullable_cast(y); else return;

This is a problem if T cannot be allocated by default. I have to do 
something like:
nullable T y = something;
if (!y) return;
auto x = non_nullable_cast(y);

That isn't so bad.