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

[12345swordy]

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.
>>>
>>> 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.
>
> [snip]
>
> 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.

> It certainly is deliberate, though. I believe it may have been 
> inspired by C++'s "friend" declarations. The comparison may 
> help with understanding why D does it this way: 
> https://dlang.org/articles/cpptod.html#friends
>
> 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.