Why do private member variables behaved like protected in the same module when creating deriving class?

[Bastiaan Veelo]

On Monday, 29 October 2018 at 13:52:47 UTC, unprotected-entity 
wrote:
[...]
> But nobody seems willing to listen to those proposals.
>
> Doesn't affect me. I already have great programming languages 
> that already do what I want them to do.
>
> I'd like to 'play' with D. But when private actually means 
> public (inside a module), and when I the programmer have no 
> control over this (within a module), then, my interest in D 
> cannot be sustained.
>
> If you have a class in a module, and you have anything else in 
> that module, then the encapsulation of your class is 
> immediately suspect - and anyone reviewing your code has to go 
> looking to see exactly what you're doing - because what the 
> class says about it interface, is irrelevant.

I hear you and understand you, but personally I still prefer the 
D spec as it is in this regard, except for the confusing aspect 
that you shouldn’t `alias this` a private member; but that is 
rather a limitation of alias, not of encapsulation.

Remember, the concept of encapsulation existed long before OO, 
arguably in a much stronger form. See the second half of 
https://forum.dlang.org/post/vjduytokawqtbvpslzpe@forum.dlang.org; as you see, you are not the first to bring this up. I can recommend the video link at the bottom of that post.