[Issue 5058] New: invariant() should not be called before opAssign()

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Oct 15 10:03:46 PDT 2010


http://d.puremagic.com/issues/show_bug.cgi?id=5058

           Summary: invariant() should not be called before opAssign()
           Product: D
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody at puremagic.com
        ReportedBy: jmdavisProg at gmx.com


--- Comment #0 from Jonathan M Davis <jmdavisProg at gmx.com> 2010-10-15 10:03:11 PDT ---
As it stands, the invariant is called before every public function is called
and after every public function is called. On the whole, this is correct
behavior. However, there is at least one case where this is undesirable:
opAssign().

Because it is quite possible to have struct which violates its invariants
(thanks to the whole init vs default constructor fiasco), it's quite easy to
have a struct which was default-initialized which you're trying to assign to
and which violates the invariant. So, the invariant fails and an AssertError is
thrown. Since, opAssign() is theoretically supposed to completely replace the
state of the object, there's no need for the object to be in a correct state
prior to opAssign() being called. It obviously needs to be in a correct state
afterwards, and if the invariant is run afterwards, it will catch if opAssign()
did not correctly replace the state of the object such that it no longer
violates its invariant. However, there's no need to call the invariant before
opAssign() is called. The state prior to opAssign() is irrelevant, and calling
the invariant just makes it really hard to have invariants in a struct where
you can't make it so that the init value for that struct doesn't violate its
invariant.

So, _please_ make it so that the invariant is _not_ called prior to opAssign()
being called.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list