Allow default constructors for structs

[monkyyy]

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.

.init sucks as a standard, I only ever use it as I have nothing 
else see my post about .zero (there is **not a standard**, 
int.init!=float.init, are ranges init even fixable? is 
nullable.init well defined? is sumtype.init?)

but this proposal does not maintain a .init "standard"

>>>S v = S.init; // ok (may be a logically incorrect object)