On Thursday, November 29, 2012 11:41:45 Mehrdad wrote: > On Thursday, 29 November 2012 at 05:31:13 UTC, Jonathan M Davis > > wrote: > > <snip> > > I'm just not understanding the whole "the default construction of > a struct should be a compile time creature, not a runtime one". > > > > Don't you have to initialize the struct with zero's either way? > > So either way, you're going to have to initialize it... so no > perf increase in any way. Why prevent the user from > default-initializing it the way he wants to?
All init values must be known at compile time, and there are a number of places in the language where init needs to be used and default construction could never be used like it is in C++. Some limited default construction which could be done at compile time could be used in such cases, but it would have to be quite limited and would generally defeat the purpose of default construction in the first place. For instance, the possibility of exceptions being thrown totally screws with things, so default constructors would have to be nothrow. They'd probably have to be pure as well (and given that they'd have to be run at compile time, there wouldn't be any mutable static variables to access anyway, so the constructor would end up being effectively pure regarldess). And really, if you have to run them at compile time (which the language requires in order to do a number of the things that it does with init values), then default constructors don't buy you much of anything anyway. You'd never be able to really do more than just default initialize all of the member variables. You'd just be doing it in the default constructor instead of initalizing them directly. The main gain from having default constructors comes from being able to do stuff like RAII where just declaring the variable is enough (MFC's hourglass is a good example of that). It has to be able to do stuff at runtime to be of any real use, but all types need to be constructable at compile time, so that just doesn't work for a type which sits directly on the stack. At best, you'd end up with an init property and a default constructor, and depending on where the type was used, it would end being default-initialized with init or default constructed with the constructor, making the potential confusion and inconsistency great, and it would completely defeat the typical purpose of the default constructor of guaranteeing a particular default state. It all comes back to having to have a default state which must be known at compile time, since D uses it all over the place (default initializing member variables, default initializing elements in arrays, setting out parameters, etc.). That feature effectively kills default construction. You can have a no- args constructor via static opCall, but it's fundamentally different from a default constructor and really doesn't fill the same role at all. - Jonathan M Davis
