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

[Jonathan M Davis]

On Friday, October 26, 2018 1:55:08 PM MDT 12345swordy via Digitalmars-d 
wrote:
> On Friday, 26 October 2018 at 19:45:48 UTC, David Gileadi wrote:
> > It certainly is deliberate, though. I believe it may have been
> > inspired by C++'s "friend" declarations. The comparison may
> > help with understanding why D does it this way:
> > https://dlang.org/articles/cpptod.html#friends
> >
> > In my opinion it reflects D's ethos of keeping the common
> > practice safe but attempting to always allow an escape hatch.
>
> If it deliberate, then it needs to be documented.

What are you asking for exactly? The documentation documents exactly what
the behavior is:

https://dlang.org/spec/attribute.html#visibility_attributes

"2. Symbols with private visibility can only be accessed from within the
same module. Private member functions are implicitly final and cannot be
overridden."

Are you looking for the documentation to explain why there is a "loophole"
to private that allows other symbols within a module to access private
members of a class of struct? As far as D is concerned, private doesn't even
really _have_ anything to do with classes or structs. It's one of the access
level attributes that you can apply to members of a class or struct (just
like you can use it on module-level symbols), but it's private to the
module, not the class or struct. It's understandable that you'd think that
it was private to the class or struct, since other languages do that, but
nowhere in the documentation does D ever say anything of the sort. It quite
clearly states that it's private to the module. So, from D's perspective,
there is no loophole. The whole idea that private is private to the class or
struct has nothing to do with D. The only reason that you think that there's
a loophole is because of preconceptions about private that you have from
experience with other languages.

The spec _could_ compare D's version of private to that of other languages
in order to show why that particular design decision was made, but that's
not the sort of thing that's usually in the spec. In general, the spec
specifies what the language is but doesn't go into detail with every little
decision about _why_ it is the way it is. Maybe it should in some cases. I
don't know. Our spec isn't very good overall, because Walter isn't good at
writing specs (and has said as much). I'd have to go study something like
the C or C++ spec to see how a spec really _should_ be written. Ours can't
seem to decide whether it's a tutorial or a proper spec. But what the
documentation says is correct about the behavior. The whole idea that
private would be anything else is just based on assumptions made after
having used other languages that have private and classes.

- Jonathan M Davis