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

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Oct 27 22:13:58 PDT 2010


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



--- Comment #6 from Jonathan M Davis <jmdavisProg at gmx.com> 2010-10-27 22:13:01 PDT ---
The problem with that is what if you don't _want_ T.init to pass the invariant?
It seems to me that if T.init doesn't pass the invariant, then really, T.init
shouldn't be used or should at least be assigned to before it's used. For
instance, SysTime in the datetime module that I've been working on has a
TimeZone class as a member. It's not possible to properly initialize it at
compile time, so you're stuck with SysTime.init with a null TimeZone - which
should _never_ happen. Any code which uses SysTime.init _should_ fail the
invariant that the TimeZone is non-null. The alternative is segmentation faults
when the null TimeZone is used. Granted, making T.init pass T's invariant would
solve the opAssign() problem, but I think that it would be bad in the general
case. I also think that it would be bad if T.init had to pass the invariant,
since then struct invariants become border-line useless in many cases. Now,
making it so that the invariant for opAssign() is run normally but not in the
case where the value is T.init, then that could work, but I don't like the idea
of making T.init pass the invariant in the general case.

If default struct constructors were possible, then the problem with
SysTime.init and inits for other structs like it could be solved, but we're
stuck for now it seems.

-- 
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