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

[Mike Parker]

On Wednesday, 8 June 2022 at 21:38:24 UTC, forkit wrote:

>
> why is so hard for people to get this point? I don't get it.
>
> It seems like such a simple concept -> an option to have a 
> member of a class that is private to that class.
>
> C'mon everyone. It's simple to get your head around.
>
> There is no part of this idea that requires anyone to change 
> what they currently do in D.
>
> It's @pure opt-in.

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. There has to be a 
compelling reason to add it. You haven't demonstrated one in this 
thread from what I've seen.

You can achieve what you want by splitting things out into 
separate files, and that's what you have to overcome in order to 
sell this idea. You keep insisting this isn't good enough, 
because even then one can always add something to a module that 
accesses private class members. But that's not really a 
compelling reason, because the solution to that exists: don't do 
it.

You keep mentioning Java. Every method in a Java class has access 
to private member variables, even when the intention is for only 
one method to modify each member variable. How do they handle it? 
By convention.

It's the exact same issue you're complaining about here. In D, 
that the functions access the private members can be outside of 
the brace closing the class definition makes no practical 
difference. If you move to class per file, you've solved your 
conceptual problem of encapsulation at the class boundary, and as 
long as you never add a function to the module that accesses 
those variables  from outside of the closing brace you're golden. 
But you still have to contend with multiple member functions 
having access to the private variables, so you still have to go 
by convention if you want to keep access to the minimum. Or 
should we also have a level of encapsulation to allow access only 
from a single function?

If you can demonstrate that the benefit of adding a new level of 
protection to the language outweighs the cost, then you'll have a 
leg to stand on. But it's a tough sell since we already have a 
way to handle it.