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

[Steven Schveighoffer]

On 7/7/18 11:06 PM, FeepingCreature wrote:
> On Friday, 6 July 2018 at 23:37:30 UTC, Simen Kjærås wrote:
>> 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.
>>
>> -- 
> 
> Yeah, sorry - that was a snap answer; union is indeed not a solution, 
> particularly since it doesn't even work for types with elaborate 
> destructors.
> 
> That said, I agree that this can be implemented, however imo the fact 
> that we have to retrace the work of the compiler in laying out the data 
> is a warning sign - imo, it happens because what we actually want is for 
> the compiler to *work a different way*, which is why we find ourselves 
> painstakingly recreating its interna in userland, except with different 
> destructor semantics. This points at a flaw in the language, imo - if we 
> so urgently need a way to express different semantics, we shouldn't have 
> to painstakingly hide the type behind the compiler's back; the compiler 
> should have our back in this instead of fighting us.

Hm... this reminds me of the recent discussion around __symbols, and how 
they are treated specially.

Could we reserve some subset of those symbols to say "treat these 
differently"?

Or have an attribute that marks a member in such a way? I'm reminded of 
of the future storage class __mutable as well.

-Steve