http://d.puremagic.com/issues/show_bug.cgi?id=5058
--- Comment #6 from Jonathan M Davis <jmdavisp...@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: -------
