What is the case against a struct post-blit default constructor?

[Simen Kjaeraas]

On 2012-05-12 00:10, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Friday, October 12, 2012 01:20:44 Dmitry Olshansky wrote:
>> >
>> > This sounds more like a limitation of invariants, rather than a  
>> problem
>> > with .init. You make (imo) a valid point.
>> >
>> > Would it be complicated for opAssign to first check memcmp(this,
>> > T.init), and only do entry invariant check if the comparison fails?
>> >
>> > Potentially ditto on exit.
>>
>> With your rule T.init is a valid state. AFAICT in Jonathan's example it
>> isn't.
>
> Yeah. All that's required is that you outright skip the call to the  
> invariant
> before calling opAssign. It _does_ mean special casing opAssign, but I  
> don't
> see that as a problem. I don't understand why it matters whether the  
> object is
> valid before it's assigned to. Presumably, you're completely replacing  
> its
> state, and regardless of what you actually do in the function, it would  
> still
> need to be valid afterwards. So, it seems perfectly fine to me to just  
> skip
> calling the variant before calling opAssign, but Walter was against it.  
> His
> comment on the bug ( http://d.puremagic.com/issues/show_bug.cgi?id=5058 )
> indicated that he thought that init should always be in a valid state,  
> but
> since NaN and null are invalid states, I see no reason that a struct's  
> init
> value can't be an invalid state. It can be copied and passed around just  
> fine.
> It just wouldn't pass its invariant if you tried to call a function on it
> before assigning it a valid value.

The opAssign can presumably be more complex, and e.g. require deallocation  
of
non-GC memory, releasing handles and whatnot.

Anyways, is there a reason you cannot use @disable this() for SysTime?  
That way,
you have rather explicitly marked .init as invalid.

-- 
Simen