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

[Mike Parker]

On Monday, 29 October 2018 at 09:25:07 UTC, unprotected-entity 
wrote:
> On Monday, 29 October 2018 at 06:15:25 UTC, Mike Parker wrote:
>> Encapsulation inside the file is rather pointless.
>
> Say that to yourself a few times, and see if your view changes 
> ;-)

I have, and it hasn't :-)

>
> (btw. just take a look at the length of some 'files', within 
> Phobos - I mean, gee, I really hope the developer of those 
> files did not share your view)

Classes can take up just as much space, presenting the same 
potential issue.

>
> In any case, encapsulation in a file, still exists, just not so 
> much for classes
> - function still have it, scope braces still have 
> it..etc..etc... but one of the most important constructs in 
> programming, the class, does not.

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.

And yes, classes do have encapsulation. Private class members are 
hidden from the public API.

>
> It's not just that it could happen 'by accident', it's that D 
> actively encourages this, by making 'private' (within a 
> module), a completely useless construct.
>
> It's there by default.

Being the default isn't the same as encouraging it.

>
> Just how often does one need to access the private members of a 
> class, within a module?

I can't speak for others, but it's a feature I use fairly often. 
I tend to design aggregates and free functions to the module, as 
a cohesive whole, rather than as separate parts. If I want 
separate parts, I put them in different modules and use `package` 
for the bits that need to stay out of the public API. Works a 
treat.