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

[Jonathan M Davis]

On Monday, October 08, 2012 18:47:43 Malte Skarupke wrote:
> So I really can't think of a reason for why you wouldn't want
> this. Yet this discussion has happened several times already.
> There is clear demand for it and very good reasons, such as those
> mentioned in all the linked discussions.
> 
> So why is this being rejected?

It buys you pretty much nothing. There are plenty of places in the language 
where init is required (e.g. member variables that can't be directly 
initialized and the elements in an array). So, init _will_ be used regardless 
of what you do with the default constructor. If you want to prevent that, then 
you need to disable init, which we can already do. But you're not going to get 
those things initialized with the default constructor, which kind of defeats 
the purpose of the default constructor. If you can't guarantee that every 
instance which isn't explicitly constructed is default constructed, then 
what's the point?

And if you want to have a way to explicitly construct a struct with no 
arguments, then you can use static opCall. Voila. Problem solved. What else do 
you need, given that you can't possibly have the struct call a default 
constructor everywhere that it's default initialized?

There's the issue of

S s;

being S.init, but that's _normal_. If you were to make it the same as S() when 
a default constructor were declared, then structs wouldn't act like every 
other single type in the language (which are all default initialized to their 
init values). It would also make it _far_ more likely for people to write a 
default constructor thinking that it was _always_ used and then end up with 
serious problems when it wasn't - e.g. when it wasn't called for the elements 
or arrays or for member variables or for module-level variables or for any 
other instance of the struct which has to use init. By making

S s;

use S.init and disallowing default constructors, we make it clear to people 
_far_ faster that they can't rely on any kind of default construction of 
structs in D. Adding a default constructor which worked with

S s;

would just hide the problem and give people the false impression that they 
could rely on default construction. static opCall provides a means of 
constructing a struct with no arguments if that's what you want. So, as far as 
I can see, it pretty much just comes down to whether

S s;

is changed to be default constructed rather than default initialized when a 
default constructor is declared. And I think that that's truly 
counterproductive. It makes structs act inconsistently with other types and 
misleads people as to how default initialization works in D, which will only 
cause more bugs.

The _only_ way that this could be reasonably solved is if you could somehow 
make it so that every time that a struct is default-initialized, it's default-
constructed instead, and D just doesn't work that way. Too many things rely on 
init and the fact that it's known at compile time.

So, IMHO adding default constructors to structs would be not only pointless 
but counterproductive.

- Jonathan M Davis