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

[unprotected-entity]

On Monday, 29 October 2018 at 10:32:00 UTC, Mike Parker wrote:
>
> I don't think I've ever heard of anyone speak of encapsulation 
> in terms of function scopes and anonymous scopes. That's a 
> fairly narrow definition. At any rate, I don't put variables 
> inside a function to keep them out of the public API.

How is that a narrow definition on encapsulation?

A function hides distracting details, and exposes a simple 
interface to its client.

What goes on inside, is mostly irrelevant to the client, as long 
as it does what it's meant to do. Typically, you can go and 
change how it does it, without affecting the client.

That's encapsulation..surely.

The argument is a little harder to make for an anonymous scope, I 
give you that, but it also can have encapsulating properties in 
any case.

There should never really be any need to get at the interior of a 
function, outside of that function? Use it's interface. That's 
why it's there.

I'm just making the same case for classes.

structs on the otherhand, well ... do what you want with 'em ;-)