Defaut initialization of structs

[Jonathan M Davis]

On Monday, October 13, 2025 4:44:58 AM Mountain Daylight Time Per Nordlöw via Digitalmars-d-learn wrote:
> Given a `struct S` is, `S()` always equivalent to `S.init`? I
> wonder which is preferred in an (parameter default value)
> expression that should evaluate to the default value of `S`.
>
> I would like to use `S()` as its shorter to type than `S.init`
> but I'm uncertain whether it can trigger execution of code
> despite D disallows nullary constructors.

Originally, there wasn't supposed to be any difference between these

    S s;
    auto s = S.init;
    auto s = S();

but changes to the language over time have made it so that they're all
subtly different. Strictly speaking, S.init is the value used to
default-initialize an object, but it's not necessarily the
default-initialized value.

The main stuff that causes differences are:

1. Structs which disable default initialization.
2. Non-static nested structs.
3. Structs which define static opCall.

If a struct disables default initialization, then

    auto s = S.init;

is legal, but

    S s;
    auto s = S();

aren't. So, in that particular situation, you almost certainly don't want to
use S.init.

If a struct is a non-static nested struct, then

    S s;
    auto s = S();

will both properly initialize the struct. However,

    auto s = S.init;

will properly initialize all of the struct _except_ for the context pointer,
which will be null. So, if the struct ever actually uses its outer context,
it will segfault. So, in that situation, you almost certainly don't want to
use S.init.

And if a struct defines a static opCall which can be called with no
arguments, then

    S s;
    auto s = S.init;

will properly initialize the struct, whereas

    auto s = S();

will do whatever the static opCall does (and there's no guarantee that the
static opCall even returns a value let alone that it returns an S). So, in
that situation, you almost certainly don't want to be using S() (and if you
do, it's because you know exactly what type you're dealing with and how it
will behave).

So, some folks have taken to using S() rather than S.init, because it
doesn't bypass the restrictions when disabling default initialization, and
it fully initializes non-static nested structs, but in generic code at
least, it's still potentially going to do the wrong thing, because a struct
could define static opCall.

This means that in the general case (and particularly with generic code),
code should use neither S.init nor S(). Rather, it should let a variable
default-initialize itself and use that. Using either S.init or S() will
result in the code doing the wrong thing at least some of the time. There
are still specific cases where you might want to use one or the other, but
normal code really shouldn't be using either unless you know exactly how the
types you're dealing with will behave - which of course means that generic
code shouldn't use either S.init or S() unless it has additional checks to
make sure that the type doesn't disable default initialization and doesn't
define static opCall.

This of course is kind of annoying in cases where you need to pass a
default-initialized value but don't need a variable - e.g. foo(S.init) - but
as far as language buit-ins go, to do the correct thing in the general case,
you need to declare a variable and use it if you want the code to be correct
regardless of the type being used. To work around this, Phobos v3 has a
helper trait to solve the problem.

    template defaultInit(T)
    if (is(typeof({T t;})))
    {
        enum defaultInit = (){ T retval; return retval; }();
    }

So, then you'd do something like foo(defaultInit!S) instead. It doesn't
actually work with non-static nested structs, because they can only be
constructed in the scope where they're declared, but in that situation,
you're dealing with a specific type that you control and will know that
static opCall wasn't declared.

However, since defaultInit is in Phobos v3 (which is nowhere near ready),
it's obviously not something that I can tell you to go use instead (outside
of copying it to your own code).

So, if you're writing generic code (particularly if it's in a pubicly
available library), you're going to want to either just declare the variable
and use it (so that it's default-initialized normally), or you're going to
want to create a helper trait like defaultInit and use that. You do not want
to be using either S.init or S() outside of some fairly specific
circumstances.

However, if you're writing non-generic code, and you know what the type in
question is going to do, then both S.init and S() should be fine. In the
vast majority of cases, there isn't actually a difference. It's just that
there are corner cases where there is a difference, and that's potentially
going to screw up generic code.

- Jonathan M Davis