(non)nullable types

[Christopher Wright]

Christopher Wright wrote:
> Nick Sabalausky wrote:
>> "Christopher Wright" <dhasenan at gmail.com> wrote in message 
>> news:gnfgj6$1484$2 at digitalmars.com...
>>> One possible change: implicit casting with an assertion that the 
>>> nullable value is not null.
>>
>> I can tell right now I wouldn't like that. That would make it far too 
>> easy to make mistakes, as it would open up a way for mistakes to 
>> circumvent the whole point of having non-nullables. If I accidentially 
>> tried to provide a nullable to something that expected a non-nullable, 
>> I'd want some sort of up-front notice so that I can either fix it or 
>> confirm "yes, I really did mean that" rather than have to hope that 
>> I'm lucky enough for the value to actually be null when I test it. An 
>> implicit cast should either "just work" with no risk of runtime-error, 
>> or be disallowed in favor of something more explicit.
> 
> I think I favor this, actually. If you don't care, you can cast 
> manually. But the implementation difference should be miniscule.

One problem here is static constructors. They're supposed to run in 
import order, I believe, so if you do this:

module A;
Object o;
static this () { o = new Object; }

module B;
import A;
static this () { writeln(o); }

That should be safe. I think.

Class member variables are also problematic. It's probably going to be 
annoying to make sure each nullable variable gets initialized in every 
constructor. I could push that off to runtime, of course, but that isn't 
so great.

Struct member variables are the killer, unless you have a struct 
constructor.