`restricted` member variables

[forkit]

On Monday, 20 June 2022 at 11:04:16 UTC, Mike Parker wrote:
> I won't rehash the private-to-the-module debate here. I've 
> always looked at it purely in terms of the public vs. private 
> interface. From that perspective, I still don't find the 
> argument that "it breaks encapsulation" a convincing one on the 
> surface.

I don't want to rehash it either, so I'll limit this to one post 
in this thread.

I have a different perspective of that debate, than yours.

You (as I understand it) see this private-to-the-module debate, 
as a debate over whether it breaks encapsulation of the class 
type.

You're argument is no, it doesn't, cause you, the programmer, 
have complete access and control of the module (in essence, you 
have encapsulation at your fingers already (the module) so why 
would you need encapsulation at the class level.

My perspective is different:

- the programmer in D cannot directly express intent here.
- the programmer in D cannot rely on the compiler to catch a 
violation of that intent.

You're argument comes down to: 'you don't need to express that 
intent, neither do you need to rely on the compiler to catch a 
violation of that intent, since you have control over the module'.

Should you're reasoning only apply to the class type, or should 
it apply to all areas of programming where you want to express 
intent, and rely on the compiler to catch a violation of that 
intent?

Thus you can see, how absurd the argument is. I hope.