What is the case against a struct post-blit default constructor?

[Jonathan M Davis]

On Thursday, October 11, 2012 08:19:23 Andrei Alexandrescu wrote:
> Could you please give a few examples? (Honest question.) Most structures
> I define have an obvious quiescent state that vacuously satisfies the
> invariant. Exceptions that come to mind are: (a) value types that must
> always allocate something on the heap, see e.g. the contortions in
> std.container; (b) values as permits (the existence of the value
> guarantees a resource has been secured, as in scoped locks on mutexes).

std.datetime.SysTime requires a valid TimeZone to function properly, but 
SysTime.init ends up with a null TimeZone, because it's a class, and you can't 
directly initialize a member variable with class object. The result of this is 
that SysTime can't have an invariant, because then SysTime.init would be 
invalid, and thanks to the fact that 
http://d.puremagic.com/issues/show_bug.cgi?id=5058 was resolved as invalid 
(the invariant gets called before opAssign even though I'd strongly argue that 
it shouldn't be), even assigning a valid value to a SysTime which was 
SysTime.init would blow up with an invariant. So, no invariant, even though it
really should have one.

Any situation where the init value is essentially invalid (like it would be 
with floating point types) makes it so that you can't have an invariant, and in 
many of those cases, having a default constructor which was always called 
would solve the problem. I'm still in favor of _not_ trying to add default
constructors given all of the issues involved, and I agree that on the whole,
init is a superior solution (even if it isn't perfect), but there _are_ cases
where you can't have an invariant because of it.

- Jonathan M Davis