Coverity tool

Michel Fortin michel.fortin at michelf.com
Wed Feb 10 20:09:25 PST 2010


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).

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.

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.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/




More information about the Digitalmars-d mailing list