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
