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