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

[unprotected-entity]

On Sunday, 28 October 2018 at 05:28:31 UTC, Mike Parker wrote:
>
> You can make the same mistake inside the class:
>
> class Foo {
>    private int x;
>    void increment() {...}
>    ...
>    void doSomethingInternal() { x++; }
> }
>
> How is making that mistake outside of that final curly brace 
> any different or any worse? It's all in the same file.

Except, that (I assume) a module in D is meant to be more than 
just a single class.

If that's not the case, then my argument is irrelevant.

If it is the case, then you presumably would have a great deal 
more code in your module, than you would in a single class. 
Hence, greater likelihood of mistakingly
accessing a private member of some class defined within the 
module, somewhere.

In any case, it does undermine the principle of encapsulation 
(assuming you agree that a class deserves to be a unit of 
encapsulation).

In, it's nothing more than a convenient hack, really.

There is not a third option here.