Allow this() { } for structs

[Q. Schroll]

On Friday, 6 November 2020 at 09:54:23 UTC, FeepingCreature wrote:
> I do not understand what purpose the lack of this() serves. I 
> mean, I understand what purpose it serves, it's so T.init is 
> always equivalent to T(), but I don't understand what purpose 
> *that* serves. T.init is *already* not a valid constructed T if 
> you want to use any invariants and/or call any methods at all. 
> We *already* can't treat them equivalently regardless, so from 
> my perspective the ban on T() serves no purpose.

I understand the reasons. Type.init is nice to have for all 
types, but, unfortunately, life isn't fair and Type.init is 
garbage for some types, not only those with invariants. One could 
argue---and I'm leaning towards that side at least 
somewhat---that an invalid Type.init is worse than Type.init not 
existing for all types. If a generic algorithm won't work without 
Type.init then it won't work with all types. Generic algorithms 
not working with all types, but only those that provide specific 
things, is nothing new.

In my opinion, if for a struct T, T() isn't @disabled and 
defined, if it is pure, the compiler can reasonably say:

     enum init = T();

If T's this() isn't pure, T.init cannot exist. Use cases where 
this() wouldn't be pure are probably rare anyway. As a first 
step, the compiler could disallow impure this() at all. That 
being said, debug{} could be used to do something at construction 
in an impure manner.