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