Allow default constructors for structs

[Quirin Schroll]

On Friday, 30 August 2024 at 12:29:43 UTC, Dukc wrote:
> monkyyy kirjoitti 30.8.2024 klo 14.11:
>> On Thursday, 29 August 2024 at 14:28:09 UTC, Ogi wrote:
>>> struct T {
>>>     S s;
>>>     // implicit `@disable this();`
>>> }
>> 
>> why? I *just* got bitten by nested structs being hard to init 
>> (with terrible error messages), why not just fix the problem?
>
> There is a reason. D is designed so that every type, except 
> `noreturn`, has an `.init` value. It's supposed to be a value, 
> not a function. This is why a struct cannot have a default 
> constructor. If we break that pattern, then we run into some 
> pretty strange situtions. For example, what would be the 
> `.init` value of a static array of structs with a default 
> constructor? What if the `.init` value of such a struct is used 
> at CTFE? If the struct is a member of another struct, should 
> the default constructor be called only once to determine 
> `.init` value of the parent struct, or every time the parent 
> struct is initialised?
>
> However, I agree that structs (and unions) with context 
> pointers are really annoying because they break that pattern of 
> `.init` value for every type. Maybe it should be allowed to 
> initialise nested structs with a null context.

Simple. Burn `init` with fire and give up the idea that every 
type has a default value. It was never true due to `void`, but 
with `noreturn`, it’s gotten worse. Adding non-nullable types is 
impossible really with also requiring each type have a default 
value.

It’s limiting the design space. We’ve gotten workarounds like 
`static opCall` that are frankly worse than the problem. C++ 
added `static operator()` and guess what, you can’t call it 
except non-statically.