Maybe we could support the following syntax, with a static this instead of this :

struct S
{
int x=11;
int y = void;

static this() // hypothetical
{
// x would already be initialized to int.init here
assert(x == int.init);
// y is left uninitialized here

y=x*x;
}
}

On Fri, May 17, 2013 at 2:34 PM, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

On 5/17/13, Walter Bright <walter@digitalmars.com> wrote:
> I oppose this. D has a lot of nice features because of the .init property.
> Default constructors wreck that.

Would they? I'm thinking the process would be:

struct S
{
int x;
int y = void;

this() // hypothetical
{
// x would already be initialized to int.init here
assert(x == int.init);

// y is left uninitialized here
}
}

Maybe that's already clear. But why is .init actually such a big
problem? If it becomes arbitrarily expensive to call .init of a
struct, well it's because it has to be - if the user really provided
an expensive default ctor. But it's entirely the user's
responsibility. So then .init can even throw, but throwing exceptions
isn't a big deal. Is there some other problem?

A custom default ctor in a struct is one of the most asked for
features. Just yesterday we spent several hours explaining to a C++
user why a default ctor doesn't work, and what .init is for. The whole
conversation could have been avoided if D had support for custom
default ctors for structs. This topic comes up very often in IRC and
the forums.