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

[unprotected-entity]

On Friday, 2 November 2018 at 00:54:43 UTC, Adam D. Ruppe wrote:
>
> If you use interfaces correctly, there will be no private 
> members accessible regardless of privacy and D's module system.
>
> interface I {}
> class B : I {}
>
> void workWithIt(I i) {
>     // nothing in B is accessible without ugly casts!
> }

".. but it would be tenuous to argue that transparency was a 
positive contributor; more plausibly, it was a risk minimized by 
intensive management." - Andrei Alexandrescu - page 200

Now, I might be accused of taking that out of context, but am I 
really?

In D, public is the default (I wonder how many realise this, when 
they come to D, let alone the issue with private).

" .. (heck, public sets the bar pretty low.. )." - Andrei 
Alexandrescu - page 202

So, in D, the bar is already pretty low?

Also, in D, there simply is no way to get privacy within the 
module.

Just how low does the bar get, in D?

(to quote informally), It's a transparent, white box, 'everything 
knows everything' approach to designing software - page 199  
(again, i could be accused of taking this out of context, but am 
i really?)

To me, D modules are 'a risk minmized by intensive management'

(perhaps using the techniques you've demonstrated ;-)

But gee, the bar is soooooo low.... in D.