Time to kill T() as (sometimes) working T.init alias ?

[Jonathan M Davis]

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