Allow this() { } for structs

FeepingCreature feepingcreature at
Sat Nov 7 08:50:43 UTC 2020

On Friday, 6 November 2020 at 16:53:32 UTC, Q. Schroll wrote:
> 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.

I used to think that T.init was required for really basic stuff 
like Nullable and sumtype, but that kind of data type *already* 
doesn't work with T.init because if it's unset, it needs to 
bypass the broken T.init destructor call. So we need to use the 
union hack there anyways, as I had to do for Nullable, and do a 
semi-complete endrun around the compiler's lifetime tracking 
regardless. That's why I think the importance of T.init is 
overstated nowadays, and adding T() probably wouldn't break 
anything fundamental.

More information about the Digitalmars-d mailing list