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

[monarch_dodra]

On Thursday, 11 October 2012 at 20:59:32 UTC, Jonathan M Davis 
wrote:
> On Thursday, October 11, 2012 13:06:34 Walter Bright wrote:
>> On 10/11/2012 10:23 AM, Jonathan M Davis wrote:
>> > but there _are_ cases
>> > where you can't have an invariant because of it.
>> 
>> Except that you could write the invariant to be inclusive of 
>> the .init
>> state.
>
> Which would completely defeat the purpose of the invariant in 
> many cases. The
> point is that it is invalid to use the init value. You can pass 
> it around and
> set stuff to it and whatnot, but actually calling functions on 
> it would be
> invalid, because its init state isn't valid. SysTime is a prime 
> example of
> this, because it requires a valid TimeZone object, but its init 
> value can't
> have one, because TimeZone is a class. So ideally, it would 
> have an invariant
> which asserts that its TimeZone is non-null, but it can't have 
> that, because
> opAssign unfortunately checks the invariant before it's called 
> (which makes no
> sense to me - why would the state of the object prior to 
> assignment matter?
> you're replacing it), so assigning a valid value to a 
> default-initialized
> SysTime would fail the invariant.
>
> - Jonathan M Davis

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.