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
