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

[unprotected-entity]

On Monday, 29 October 2018 at 06:15:25 UTC, Mike Parker wrote:
>
> Anyway, I'm not the one who needs convincing. And I have a high 
> degree of confidence that the ones who do need convincing won't 
> be. There has yet to be a strong enough argument to change this 
> behavior.

If anything, someone should be trying to convince me, to use D ;-)

I do not believe, that a case can be made, to alter the status 
quo (if for no other reason, than to ensure existing code, keeps 
working).

Howver, I have seen, on many occassions now, where this issue has 
popped up, along with ideas on how to possibly solve it. On each 
occassion, the idea gets put to rest very quickly, by some, one 
way or another.

I think that is a real shame.

A way to make a class member private, within a module, is an idea 
worthy of consideration, and has immediate practical value, both 
in terms of convincing people to use D, and also in better 
guarantees around the correctness of your code.

The only argument for dismissing these ideas, when they pop up, 
seems to be, that nobody would ever be able to convince 
Walter/Andrei.. so why bother pursuing it any further.

They are the stewards of the language, I get it, but I think 
that's a sad state of affairs.

Inside a module, a private member of a class is a good, useful, 
practical construct (and I thought D was practical?).