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

[12345swordy]

On Friday, 26 October 2018 at 20:22:14 UTC, Craig Dillabaugh 
wrote:

> But this loophole doesn't really provide you any mechanism to
> breaking other people's code that you don't already have.
I don't want class B to inherent class A private variables in the 
same module! If I want to do that I use the protected keyword in 
class A, that why the keyword
"protected" exist in the first place! It occupied unwanted space, 
and creates unwanted complicity!

>  You write
> the module, and if you want to be extra safe you can follow the
> convention of implementing each class in its own module.
>
I am not talking about encapsulation, I am talking about 
inheritance.
To put it simply, I am not asking who can open the door or not, I 
am asking that if the door should exist in the first place.
> [clip]
>>>
>>> In my opinion it reflects D's ethos of keeping the common 
>>> practice safe but attempting to always allow an escape hatch.
>> If it deliberate, then it needs to be documented.
>
> But it is:
> https://dlang.org/spec/attribute.html#visibility_attributes
If it is, then I wouldn't be having this conversation. I didn't 
know that derived class inherent private variables members of the 
parent class in the same module.