Allow user defined struct constructor

[IgorDeepakM]

This is regarding the disallowed user defined constructor in D.

struct S
{
    int x;
    int a[];

    this() // not allowed
    {
        x = 1;
        a = new int[10];
    }
}

The biggest obstacle is when you need a non-trivial constructor in struct, typically you need to allocate something. You don't need any parameters but just a parameters less constructor.

This one of the more weird decisions of D and despite this has been discussed several times over the years, I find no real explanation why this wouldn't be possible but answers about the benefits of a non-trivial constructor. Despite of this, non-trivial functions is still allowed after the constructor just as normal.

From: https://wiki.dlang.org/Language_issues#Default_constructors

Advantages of .init

According to Walter Bright, some advantages of .init over default >constructors are:

• the default object is trivially constructable and cannot fail (for nested struct .init contains null context pointer, use default constructor instead)
• an easy way for other constructors to not have overlooked field initializers, so they get garbage initialized like in C++
• generic code can rely on the existence of trivial construction that cannot fail
• dummy objects can be created, useful for "does this compile" semantics
• an object can be "destroyed" by overwriting it with .init (overwriting with 0 is not the same thing)
• when you see: T t; in code, you know it is trivially constructed and will succeed
• objects can be created using TypeInfo

By these explanations, I don't see really why a user defined constructor wouldn't be possible but rather indolence.

One of the reason is that the default constructor is linked to .init, however there is not real reason why that should be the case. In C++ the struct constructor is just a function and there is no reason it can just be a function in D as well, different from .init. A struct can have both a .init and another default constructor. Between those, you can do optimizations like value not used optimization in order to merge them.

Instead I think D should go the C++ route and define what is a non-trivial constructor and a trivial constructor and the compiler should flag the constructor accordingly. If there are cases where a non-trivial constructor is not allowed, I think that would be a better place to disallow non-trivial constructors than just totally ban them all together.

Such change I think can be more difficult as there might be corner cases where non-trvial constructors are not welcome. However, I think the original D project took a wrong turn by not going the extra mile to make the syntax look clean for such fundamental functionality. If we can make this work, is this a non breaking change as they aren't allowed in old D code?

[adamdruppe]

I'm not against it, but I do suspect the implementation is easier said than done.

[IgorDeepakM]

No - the default constructor should never ever throw or fail in any other way.

Could you please explain why this is so important while it is totally acceptable in C++.

[quickfur]

Because it can leave objects in an invalid, half-initialized state, which is one of the plagues of C++.

Here's a typical example:

struct A {
    B b;
    C* c;
    this() {
       c = allocateResource();
    }
    ~this() {
        freeResource(c);
    }
}
struct B {
    this() { throw new Exception("oops"); }
}
void main() {
    A a;
}

When main constructs a, A's ctor is invoked, which implicitly calls B's ctor. However, B's ctor throws an exception, leaving a partially initialized (A's ctor never got to the line that initializes A.c). Since the exception is not caught, main is unwinded and a must now be destroyed. This calls A's dtor, which tries to free a resource that had never been initialized (A's ctor aborted before this).

This is not so bad when A is a class, because main would only see a null when the ctor fails. However, a struct continues to exist in spite of failed initialization (main could have caught the exception and ignored it, for example), in an invalid state. This leads to all sorts of weird corner cases where bugs tend to abound in your typical C++ codebase (I've seen a lot of those in my day job).

To mitigate this, default ctors must never throw.

[ntrel]

@quickfur thanks for the example. D should not have default constructors. With explicit non-default nullary constructors, I think the problem would be no worse than existing struct constructors. This is because b would have to be purposefully constructed in A.this() by calling b = B(); (and A a = A(); in main).

[IgorDeepakM]

Because it can leave objects in an invalid, half-initialized state, which is one of the plagues of C++.

In C++, 99% the of cases you will not care about catching exceptions from constructors which will make the program terminate so using a half-initialized objects will never happen. In the cases you do catch the exception, then you have to take measures in order to ensure you don't use the failed object. Will you accidentally use the object anyway in that case?

[Lyratelle]

Be ensured that all these "wrong by default"-features that C++ allows for ARE used. So such bugs DO happen - more often than one might think. This is because each an every new C++ developer has to learn to avoid them the hard way - and because nobody sane stays with C++, there need to be new C++ developers all the time.
Additionally real out-of-memory errors are such rare events nowadays (at least on test-machines), so it is very likely that such kind of hard to find bugs are never corrected. Time-bombs in most existing C++ applications. Or how do you explain that you need "security updates" of almost every big SW package on a daily basis?