Invariants are useless the way they are defined

[Andrei Alexandrescu]

On 8/25/13 2:56 PM, Jonathan M Davis wrote:
> On Sunday, August 25, 2013 14:16:28 deadalnix wrote:
>> As they are defined now, invariant are plain useless. I find
>> myself disabling them one by one in my code as soon as cases get
>> outside simple trivia.
>>
>> The problem is that invariant are checked at the beginning/end on
>> public function calls. As a consequence, it is impossible to use
>> any public method in an invariant.
>>
>> For instance, just right now I did refactor a struct to use
>> bitfields, in order to make it more compact. Now I have to remove
>> the invariant as field access are now function calls.
>>
>> Another typical situation is when you want to assert certain
>> properties in a class hierarchy, where calling virtual method is
>> part of the invariant check.
>>
>> invariant should (and must to be useful) be inserted at callee
>> point, when the callee isn't itself subject to invariant
>> insertion, and around public memeber manipulation (when the
>> manipulator isn't subject to invariant insertion).
>>
>> Any other pattern it doomed to create infinite recursion for non
>> trivial invariant checks.
>
> What drives me nuts is the fact that it gets checked when opAssign is called
> (rather than just when exiting it). That makes it impossible to have a member
> in an invalid state (either through an init which has an invalid state similar
> to how floating point values due or because the object hasn't been initialized
> yet) and have an invariant. At present, emplace will blow up in your face if
> you try and have an invariant with such types.

emplace() should not call assignment for elaborate types.

Andrei