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

[Jonathan M Davis]

On Monday, October 29, 2018 7:52:47 AM MDT unprotected-entity via 
Digitalmars-d wrote:
> On Monday, 29 October 2018 at 10:32:00 UTC, Mike Parker wrote:
> > 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.
>
> Well. In the end, it seems like nobody will be able to convince
> Walter and Andrei (and you too it seems), that there is some real
> practical merit, in allowing a class within a module, to have the
> capacity to protect its private parts.
>
> I find that really odd. (I mean, really, really odd).

If anything, many of us have been convinced of the opposite by actually
using D. The way that D treats private is pratical and useful, and adding a
way to further restrict access to member variables of classes would just be
a further complication to the language with little to no pratical benefit.

If you don't like that, that's fine. I don't think that any of use like
_every_ design decision made in D, but many of us do like this design
decision, and plenty of folks had a negative reaction to it when they
initially found out. However, experience tends to show that D's design
decision here works extremely well.

- Jonathan M Davis