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

[Jonathan M Davis]

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.

- Jonathan M Davis