On Thursday, 5 September 2024 at 17:46:18 UTC, Quirin Schroll wrote:

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

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

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?

On Thursday, 5 September 2024 at 18:17:33 UTC, Paul Backus wrote:

In principle, yes. If every data member’s type T supports T(), I consider it having a default constructor. The reason why T() works is irrelevant, maybe excluding static opCall.

Because defining any constructor makes the compiler not generate a default constructor. It’s a way to say: Give me the default constructor without spelling it out. Maybe I’m leaning too much into the C++ direction, and this() {} would absolutely work. But generally, default this(); would make the default constructor have attributes and this() {} would not. If that’s the only difference, it maybe isn’t worth it.

On Friday, 6 September 2024 at 09:45:39 UTC, Quirin Schroll wrote:

My point is: so far, we have been fine with requiring the programmer to spell it out in other cases. Why is that unacceptable in this case specifically?

Maybe the answer is, "it's not just a problem in this case, the programmer shouldn't have to spell it out in any of those other cases either." If so, then this should be a more general language feature, with its own DIP separate from any default-constructor proposal.

On Thursday, 5 September 2024 at 17:46:18 UTC, Quirin Schroll wrote:

Apparently Zig is also about to adopt .init/.default/.empty during variable declaration. Even if there is no ctor/dtor (RAII).

https://ziggit.dev/t/prefered-method-to-initialize-generalpurposeallocator/5875/13

On Sunday, 8 September 2024 at 00:00:49 UTC, Matheus Catarino wrote:

As I read the thread, it’s specific to GeneralPurposeAllocator and other structs for which compile-time default initialization can’t be done. Zig’s init is a fully formed object that is a run-time-initialized value specifically crafted for each type that has it, very much unlike D’s inits.

Part of Zig’s dogma is that everything that happens has to be explicit. Technically, there are no destructors in Zig, just functions you’re supposed to call after an object isn’t needed anymore, which you normally do using defer. The difference is, every use of an object requires a defer deinit();, i.e. there is no implicit destructor call. In D, we’re comfortable with destructors and other implicit stuff, so a declaration implicitly calling a default constructor is very much in line with what D does elsewhere. It’s not even close to being that implicit as a destructor call, actually.

“Make interfaces easy to use correctly and hard to use incorrectly.” ―Scott Meyers https://www.aristeia.com/Papers/IEEE_Software_JulAug_2004_revised.htm

A struct type for which S s; s.f(); doesn’t really work, but S s = S(); s.f(); is bad design.

On Friday, 30 August 2024 at 15:17:06 UTC, Steven Schveighoffer wrote:

+1 for default constructor