Struct default constructor - need some kind of solution for C++ interop
Nick Treleaven via Digitalmars-d
digitalmars-d at puremagic.com
Sat Sep 10 03:32:45 PDT 2016
On Wednesday, 7 September 2016 at 11:20:18 UTC, Lodovico Giaretta
wrote:
> I guess the only thing you can ask and obtain here (I mean,
> with a bug report) is that @disable this() should be allowed to
> coexist with static opCall(). That would prevent your users
> from instantiating structs the wrong way (both nested in other
> structs and on the stack).
Or perhaps explicit this() could be allowed if we have `@disable
S init` defined for S:
S s; // error, S.init is disabled
S s = S(); // OK
So how would this deal with Walter's 4 axioms:
> 1. So S.init is a valid initializer
No, S.init is disallowed. Any code that needs it should fail to
compile.
> 2. So all instances of S can be guaranteed to contain a valid
> instance
Yes, because the only instances that exist are those explicitly
constructed by constructor call.
> 3. So default initialization is guaranteed to succeed
No, this is disallowed (see 1).
> 4. So any struct constructor starts with a valid state
This can be handled by initializing fields to their respective
.init values before any constructor of S is called.
More information about the Digitalmars-d
mailing list