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

[12345swordy]

On Friday, 26 October 2018 at 18:45:32 UTC, Stanislav Blinov 
wrote:
> On Friday, 26 October 2018 at 18:16:38 UTC, 12345swordy wrote:
>> Mike Parker told me that this is intentional and not a bug.
>
> It's not a bug.
Is this really necessarily?

> Why "however"?

Class private member variables are behaving like they protected 
class protected when creating derived class in the same module.



> There's no contradiction. Within a module, you have access to 
> everything.
This is about inheritance not encapsulation. You shouldn't be 
accessing doors when they shouldn't exist in the first place.

>> Why private member variables behave like protected member 
>> variables in the same module?
>
> Because according to the spec, "Symbols with private visibility 
> can only be accessed from within the same module."

Was referring to class member variables not the module member 
variables.
> It's *your* module.
There are cases where is not necessarily "my" module but rather 
it is the "team" module.
>There's absolutely no need for
> artificial restrictions.
Nonsense, @safe and @nogc are artificial restrictions. Code 
discipline is good behavior, even for yourself.
> To keep your desk drawer tidy you, well, keep it tidy, not mess 
> it up and throw away the key.

How I organized my desk drawer is up to me though.
>> Can you explain your thought process when it comes to this 
>> design decision Walter Bright?
>
> I'm sure Walter should be honored to be graced with such an 
> eloquent inquiry.
Is that sarcasm?