T.init, struct destructors and invariants - should they be called?

[Simen Kjærås]

On Friday, 6 July 2018 at 12:31:50 UTC, FeepingCreature wrote:
> On Friday, 6 July 2018 at 12:10:58 UTC, Simen Kjærås wrote:
>> The rest looks sensible to me, but I have to say this is 
>> bollocks. This Nullable never has to construct an S.init:
>>
>> struct Nullable(T) {
>>     ubyte[T.sizeof] _payload;
>>     bool _hasValue;
>>
>
> Come on, at least make it a union with a void[]. This way will 
> fail with any struct that requires a certain alignment. Not to 
> mention that you can stick a class in it and it'll be garbage 
> collected, because ubyte[] must not store pointers to GC memory.
>
> Which makes the point, really - this is an utterly blatant, 
> unreliable, fragile hack.

The union brings back the exact problems we're trying to avoid. 
It also makes it impossible to handle types where 
hasElaborateAssign is true and this() is @disabled at the same 
time. There's also the issue that at best it will do the wrong 
thing when you @disable this() and init, but you probably 
shouldn't do that anyway.

As for alignment, GC, and possibly other things, the code was not 
intended as a complete implementation of Nullable, only to show 
that an actual member of type T is not necessary. These issues 
are fixable, if perhaps nontrivial in some cases.

--
   Simen