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

[Steven Schveighoffer]

On 11/1/18 10:29 AM, Atila Neves wrote:
> On Wednesday, 31 October 2018 at 20:46:05 UTC, Zot wrote:
>> On Monday, 29 October 2018 at 09:25:07 UTC, unprotected-entity wrote:
>>> Just how often does one need to access the private members of a 
>>> class, within a module?
>>
>> a lot actually. e.g. unittests
> 
> Unit tests should go through the public interface like anyone else. All 
> private members and functions are implementation details that shouldn't 
> matter and shouldn't break any tests if they're all removed.

So... don't test private functions? I do all the time. I want to test 
every single function I can.

I also look at internals, especially when I find bugs about them that 
can be caught with a peek at internal data.

Perhaps the internals implement some protocol, and you want to check 
it's in the right state part-way through a transaction.

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.

-Steve