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

[unprotected-entity]

On Monday, 29 October 2018 at 10:32:00 UTC, Mike Parker wrote:
>
> I can't speak for others, but it's a feature I use fairly 
> often. I tend to design aggregates and free functions to the 
> module, as a cohesive whole, rather than as separate parts. If 
> I want separate parts, I put them in different modules and use 
> `package` for the bits that need to stay out of the public API. 
> Works a treat.

Well. In the end, it seems like nobody will be able to convince 
Walter and Andrei (and you too it seems), that there is some real 
practical merit, in allowing a class within a module, to have the 
capacity to protect its private parts.

I find that really odd. (I mean, really, really odd).

That doesn't translate to..hey ..lets change the way 'private' 
works within a module  ...so that we can break everyones code...

But there are realtive easy ways to give the programmer more 
choice over this, without 'complexity' becoming a geniune issue 
(that's just used by some as an excuse not to do anything).

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.