Coverity tool

Ary Borenszweig ary at esperanto.org.ar
Thu Feb 11 04:50:33 PST 2010


Michel Fortin wrote:
> On 2010-02-10 22:54:40 -0500, Ary Borenszweig <ary at esperanto.org.ar> said:
> 
>> Ary Borenszweig wrote:
>>> Michel Fortin wrote:
>>>> unittest {
>>>>     NonNullable!Object o;
>>>
>>> Here o is null.
>>
>> Sorry, just read the class comments. But if this can't be implemented 
>> without compiler support... then it's not of much use. :-(
> 
> To recapitulate the documentation comment at the top of NonNullable: it 
> is indeed null until the first assignment. It's non nullable in the 
> sense that you can't make it null, but it still can be null if you 
> assign nothing to it. It means that if you encounter a null value in a 
> non-nullable you know it was never initialized. So the obvious place to 
> look is where it should have been initialized. I really wonder how bad 
> this would be in practice (I haven't used it much yet).

That makes sense. :)

> Unfortunately, there isn't a better way to implement NonNullable at the 
> moment. An option could be to throw immediately at construction, but 
> constructors with no arguments are not available for structs, and I'm 
> not sure it'd be so great anyway.

Maybe in D2 you will be able to put @disable to the default constructor 
of the struct, so you'll have to explicity assign something to it.

> There is also the issue of lack of polymorphism: a NonNullable!MyObject 
> variable won't implicitly convert to NonNullable!Object, although I've 
> been able to make it work for non-construction assignments using a 
> template opAssign.
> 
> So I agree with you that it's of limited utility. I think it can still 
> be useful at times. What would be great is non-nullable by default, but 
> that's another thing entirely.

Yes, I think non-nullable by default is better.



More information about the Digitalmars-d mailing list