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

[Ola Fosheim Grøstad]

On Wednesday, 8 June 2022 at 05:42:10 UTC, forkit wrote:
> But an ability to put up a barrier around some aspect of a 
> class, using 'private' for example, is clearly a benefit. Where 
> is the downside?

There would be no downside if D was willing to take a breaking 
change, but that is unlikely.

> A module containing a large number of related, but potentially 
> leaky abstractions, doesn't sound that great to me ;-)

Then write a linter that  does what you want.

If nobody cared enough about this to write and use a linter then 
that suggests that not enough people care about it enough to 
warrant a language change.

Ooor just prefix internals with underscore and be disciplined 
within the module. Not too hard  actually.

> Something I need, and something I rely upon.

Just write the linter, if it gains traction then that is proof 
that a language change should be considered.

>> Actually, it often does in my code. I use it to prevent 
>> creation of the class outside the factory.
>
> Nonsense. When you break the barrier, you've broken the 
> encapsulation. Full stop. No if and buts about it ;-)

This is not correct. Private constructor+one friend gives tighter 
control than public constructor and no friend.

If you use one factory for many classes then that gives MUCH 
tighter control.

> I accept that by breaking the barrier, you might have made your 
> job easier. That's fine also.

Not easier. There is no other way to tighten control.

Hence better encapsulation.