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

[12345swordy]

On Thursday, 1 November 2018 at 17:58:34 UTC, Atila Neves wrote:
> On Thursday, 1 November 2018 at 16:19:57 UTC, 12345swordy wrote:
>> On Thursday, 1 November 2018 at 14:17:13 UTC, Atila Neves 
>> wrote:
>>> On Monday, 29 October 2018 at 23:15:58 UTC, 
>>> unprotected-entity wrote:
>>>> On Monday, 29 October 2018 at 15:50:56 UTC, Jonathan M Davis 
>>>> wrote:
>>>>>
>>>> It's not (just) that I don't like it, it's that I don't like 
>>>> not giving the programmer the tool to better encapsulate 
>>>> their code (specifically classes) *within* a module.
>>>
>>> You don't need to protect code in your module from other code 
>>> in your module. If you do, put them in different modules.
>> That typically involves creation of files, which is not always 
>> ideal if you are working with code that is considerably small.
>
> If the code is considerably small you don't need private. You 
> don't need any good engineering principles at all, use goto to 
> your heart's content. It just doesn't matter.
Not the point. We talking about encapsulating code which involves 
creation of another modules which always involved in creation of 
another file. Which is not always good solution if your code is 
remarkably small.

> That makes as much sense to me as introducing a keyword to 
> protect a class from itself.
It the equivalent of building another house to give your new 
child its own room, when you can simply assign a room in the 
house that you already have.