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

[Craig Dillabaugh]

On Friday, 26 October 2018 at 19:55:08 UTC, 12345swordy wrote:
> On Friday, 26 October 2018 at 19:45:48 UTC, David Gileadi wrote:
>> On 10/26/18 12:27 PM, 12345swordy wrote:
>>> 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.
[clip]
>>
>> Whether this loophole is desirable and useful is a matter of 
>> opinion.
> Yes! Someone knows what I am talking about! I don't want to 
> break other people code that depends on this loophole. I just 
> want a way to close this loophole, by using the final keyword.

But this loophole doesn't really provide you any mechanism to
breaking other people's code that you don't already have.  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.

[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