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

[Dmitry Olshansky]

On 12-Oct-12 01:16, monarch_dodra wrote:
>>> 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.
With your rule T.init is a valid state. AFAICT in Jonathan's example it 
isn't.

-- 
Dmitry Olshansky