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

[Neia Neutuladh]

On Mon, 29 Oct 2018 05:13:22 +0000, unprotected-entity wrote:
> I wonder if that would still be the case, if millions and millions of
> C++/Java/C# programmers suddenly came over to D (and discovered, likely
> by accident, or by some obscure bug in their code), that a class is not
> considered a unit of encapsulation anymore.

Java, C++, and C# all treat `private` differently, so if you're saying we 
should do the exact same as they do, your request is inconsistent and 
therefore unsatisfiable.

I think this is the third time I've pointed it out.

> I think Go and Rust have done it better, somewhat, in that they don't
> even have classes. So you are forced to rethink your design anyway (if
> you want to use those languages)

Go and Rust use `private` the same as D. Shouldn't we cater to programmers 
familiar with those languages by making `private` work like they expect?

> Yes, there are situations in which it might be useful, I get it. But
> surely not every situation?

Which is why Swift has five different protection levels (but it skipped 
`protected` for some reason). That's a bit more complexity than I think is 
warranted.