Using closure in function scope to make "real" private class members

[forkit]

On Thursday, 9 June 2022 at 00:38:56 UTC, Mike Parker wrote:
>
> We get your point just fine. That's not where the pushback is 
> coming from. Like I've already told you, any new language 
> feature has to justify its existence. New features add 
> complexity to the language implementation and the cognitive 
> load....

The cognitive load is put onto me, when I come to D.

That becasue the D module system decides my specification for me, 
by making private, public within the module.

I have no say in this, other than these 'work arounds' that you 
insist I follow - including the best one yet 'just don't do it'.

Work-arounds is not a feature that D should be proud of.

I do not have to make the case for there being a need to make a 
part of a specification of an abstraction, truly private to that 
abstraction. That argument has been made decades ago, and proven 
to be a valid, and a highly useful, and highly used, design 
feature - even more so, when the compiler is able to enforce 
those invariants, which D cannot do.

So without an 'option' like I've suggested, the actual 'cognitive 
load' is put on to those that come to D.

IMO, without justification.