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.
