Structs are Not Plain: A call for empty struct constructors

[Jonathan M Davis]

n Thursday, September 19, 2019 10:42:51 PM MDT Max Samukha via Digitalmars-d 
wrote:
> On Thursday, 19 September 2019 at 20:25:53 UTC, Jonathan M Davis
> wrote:
> It has to do
>
> > with how D was designed with the idea that every type has an
> > init value which is known at compile time, and various
> > operations rely on being able to simply blit that init value.
>
> We understand the rationale behind the design. The point is that
> the idea has never worked. If you define a destructor, you most
> certainly want the object to be non-trivially initialized at run
> time. New instances of
> that type, even "branded" with .init, are NOT initialized - they
> are in an invalid state. That is why almost every D struct with a
> destructor is compelled to implement those opCall/external
> constructor/lazy initialization hacks.

Sure, the situation is not perfect, but on the whole, IMHO, it works quite
well. What it comes down to is that having init the way we do solves a set
of problems that C/C++ has but introduces other problems. There is obviously
some disagreement on whether the tradeoff is worth it. Personally, I don't
think that the problems introduced merit trying to make it so that structs
don't have their default value be init.

Regardless, even if we all agreed that we needed to add default constructors
for structs, that requires a DIP that goes into great detail about how
that's going to work with everything that currently requires that init be
the default value for a struct and that it be known at compile time. Given
how init works in D, it is not a simple matter to add default constructors,
and complaining about it in the newsgroup isn't going to change anything. An
actual plan of action would be required, and Walter would have to be
convinced that the result is better than what we currently have. Anyone here
is free to put in that time and effort if they feel that strongly about it.

- Jonathan M Davis