Disallowing S() when struct S has a constructor

[Paul Backus]

On Thursday, 5 September 2024 at 17:46:18 UTC, Quirin Schroll 
wrote:
> - 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.

Wouldn't it be easier to just forbid user-defined `.init` 
properties? It's a breaking change either way.

> - A default constructor is only implicitly present if all data 
> members have a default constructor and no constructor is 
> explicitly defined.

Would this also apply if some members have default constructors 
and the others are things like integers or POD structs?

> - A default constructor can be explicitly set to be the 
> generated one using `default`: `default this();`

We already have compiler-generated default implementations for 
copy constructors and `opAssign`, and neither of them support 
this kind of explicit declaration. Why is it necessary to have 
this for default constructors, if it wasn't necessary for copy 
constructors and `opAssign`?