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

[Jonathan M Davis]

On Sunday, October 28, 2018 2:36:06 AM MDT unprotected-entity via 
Digitalmars-d wrote:
> On Saturday, 27 October 2018 at 16:19:03 UTC, Steven
>
> Schveighoffer wrote:
> > This isn't correct. I'd write examples in each of those
> > languages, but don't have the time right now.
> >
> > -Steve
>
> I have plenty of time ;-)
>
> (in any case, my point is not to make an argument out of this, I
> was stating a fact).
>
> That D does it differently, is fine, if that's how D want to do
> it.
>
> But people coming to D, will be very surprised, and will have to
> come to terms with it, or not.

True enough, but in reality, it seems that most people coming to D don't
even notice. After all, none of the code outside of the module containing
the class has access to the class' private members, and if you don't try to
access the class' private members using any of the other code inside the
same module, then you won't notice. Plenty of folks incorrectly assume that
D's private works the same as private in other languages, never run into
problems with it, and have no clue that it works any differently. It really
only matters when you're actually looking to emulate friends, and then you
find out pretty fast. Occasionally, it comes up and folks complain about it,
but honestly, I don't think that there have been threads complaining about
it in the newsgroup more than a handful of times - if that - over the last
ten years. Mostly, if it does come up, it's just that's someone is suprised
to finally find out that private is private to the module and not the class.
I don't think that it's uncommon for folks code for years in D without
realizing it. Sure, once someone learns about it, they have to come to terms
with it, and they may or may not be unhappy about it, but it's such a
non-issue in practice that a lot of folks simply don't notice.

- Jonathan M Davis