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

[Q. F. Schroll]

On Thursday, 1 November 2018 at 17:59:35 UTC, Steven 
Schveighoffer wrote:
> However, I would *love* to be able to specify unit tests that 
> *can't* access private internals for testing purposes. IIRC, it 
> was proposed at some point to require this for documented 
> unittests.

How about public and private unittest?

As a unittest is not a symbol, public and private cannot apply in 
the usual manner. In that context, a public unittest -- even in 
the same module -- is meant to test the public interface of 
something and therefore cannot access private state. A private 
(the default) unittest, on the other hand, tests private state.
As another consequence, public (and private) with colon or braces 
do not apply to unittest; unittests must be marked directly. We 
could introduce "public unittest:" or even require syntactically 
that public (and private) are written after "unittest", i.e. 
"unittest public { ... }" to reduce confusion with visibility 
attributes.

I once whished for that feature, too, and forgot about it.