struct S
{
    int i;
    this(int);
}

S a = {}; // error, use ctor instead
S b = S(); // fine!

Why isn't the last line also disallowed (like a's struct initializer) when there's a constructor? If the answer is that struct constructors don't need to be called to create a valid struct instance, then why disallow the struct initializer?

It's also inconsistent with classes. If you want a default initialized literal you can write S.init. There is one difference for nested structs, that S() will do runtime initialization of the context pointer hidden field.

Allowing S() means we can't diagnose code trying to call a variadic constructor with no arguments - it silently fails:

struct S
{
    this(int[]...) { writeln("ctor"); }
}

void main()
{
    S s;
    s = S(); // huh, no ctor call
}

Should we make S() for any struct an error in the next edition?

On Thursday, 29 August 2024 at 16:44:46 UTC, Nick Treleaven wrote:

I meant any struct with a constructor.

On Thursday, 29 August 2024 at 16:44:46 UTC, Nick Treleaven wrote:

I have a bold suggestion instead -- let's just start having default constructors.

What's stopping us? We are on the cusp of ridding ourselves of magic runtime hooks, they are all now becoming templates.

For instance, setting the length of an array now calls a template and that template could just call the default constructor if it exists.

Then this whole mess of what S() means vs S.init, or whatnot becomes much more sane.

It's something we should start thinking about and discussing.

-Steve

On Friday, 30 August 2024 at 15:17:06 UTC, Steven Schveighoffer wrote:

I have a much less radical proposal. A struct with a default constructor can only be initialized by a constructor call, just like a struct with a disabled default constructor.

On Friday, 30 August 2024 at 16:58:25 UTC, Ogi wrote:

There is currently one situation in the D language where S() and S.init have different results: when S is a nested struct (that is, defined inside a function).

In this situation, S() produces an instance with its context pointer properly initialized to point to the enclosing stack frame, and S.init produces an instance with its context pointer set to null.

This is, for all intents and purposes, a (compiler-generated) default constructor. Additional code is executed at runtime when you use S() instead of S.init.

Furthermore, if you use default initialization with one of these structs, it behaves like S(), not S.init:

void main()
{
    int n;
    struct S
    {
        void fun() { ++n; }
    }

    S s;
    assert(s is S());
    assert(s !is S.init);
}

For the sake of consistency, if we allow user-defined default constructors for structs, they should behave the same way.

On Thursday, 29 August 2024 at 16:49:03 UTC, Nick Treleaven wrote:

I think the current behavior is fine. As people said, you can disable the default constructor if needed. A change like this would break too much code, making any benefit a bit useless.

On Friday, 30 August 2024 at 15:17:06 UTC, Steven Schveighoffer wrote:

I also don't like this for the same reason. Will break things that currently work fine.

On Friday, 30 August 2024 at 16:32:21 UTC, Jonathan M Davis wrote:

The right course of action is:

• Deprecate init. Replace it with default(T) (read: “default of T”) which gives you an uninitialized object of type T that might or might not be usable. It can’t be hooked (unlike init) because default is a keyword. A constructor transforms a the default(T) object into an object that satisfies the invariants of T if any. In general, using default(T) is a bad idea unless you do it knowing full well what you’re getting.
• Allow default constructors. Those are called on T() or variables declared of type T that are not explicitly initialized. T x; calls the default constructor of T.
• A default constructor is only implicitly present if all data members have a default constructor and no constructor is explicitly defined.
• A default constructor can be explicitly set to be the generated one using default: default this();

Initialization of a variable:

T x = void; // random garbage; do not use
T y = default; // y contains T’s default; do not use, unless you know it’s okay
T z; // default constructor runs on z; safe to use

x.__default(); // bits default(T) onto x
x.__ctor(args); // runs a constructor on x, which in general expects that x is default(T)

Essentially, T y = default; is equivalent to T y = void; plus y.__default(); both are @system.
And T z; is equivalent to T z = default; plus z.__ctor() and the language knows that this isn’t inherently unsafe, i.e. @safe depends on the constructor.

C++ has had default constructors forever. It’s one of the few decisions where I’m convinced that C++ got it right and D isn’t. “Variable declarations must be cheap” is a dogma that I’d expect in a language like C or Zig, not in a language like D, where frequently, safety wins over performance. The fact that I can declare a variable in D and it might not be safe to use is a problem.

In C++, if you design a data structure or algorithm, the question whether a type parameter T must be default-constructible has an obvious answer (to me at least).

Last but not least (I cut it out, but you did mention it), D has static opCall, which IMO is a worse design than having default constructors because it means that T() can mean one thing or another, but worst, it may not return a T at all! Just thinking about it, init need not have the right type as well. (And some other magical properties like tupleof, sizeof, and other ofs can be defined to lie, too.)