On 2012-05-12 00:10, Jonathan M Davis <[email protected]> wrote:
On Friday, October 12, 2012 01:20:44 Dmitry Olshansky wrote:
>
> 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.
Yeah. All that's required is that you outright skip the call to the
invariant
before calling opAssign. It _does_ mean special casing opAssign, but I
don't
see that as a problem. I don't understand why it matters whether the
object is
valid before it's assigned to. Presumably, you're completely replacing
its
state, and regardless of what you actually do in the function, it would
still
need to be valid afterwards. So, it seems perfectly fine to me to just
skip
calling the variant before calling opAssign, but Walter was against it.
His
comment on the bug ( http://d.puremagic.com/issues/show_bug.cgi?id=5058 )
indicated that he thought that init should always be in a valid state,
but
since NaN and null are invalid states, I see no reason that a struct's
init
value can't be an invalid state. It can be copied and passed around just
fine.
It just wouldn't pass its invariant if you tried to call a function on it
before assigning it a valid value.
The opAssign can presumably be more complex, and e.g. require deallocation
of
non-GC memory, releasing handles and whatnot.
Anyways, is there a reason you cannot use @disable this() for SysTime?
That way,
you have rather explicitly marked .init as invalid.
--
Simen
