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

[Atila Neves]

On Friday, 2 November 2018 at 12:53:44 UTC, Stanislav Blinov 
wrote:
> On Friday, 2 November 2018 at 11:43:13 UTC, Atila Neves wrote:
>> On Thursday, 1 November 2018 at 17:59:35 UTC, Steven 
>> Schveighoffer wrote:
>
>>> So... don't test private functions?
>>
>> Precisely.
>>
>> Caveat: test them if you *really* want to, but be prepared to 
>> delete the tests with extreme prejudice.
>>
>> I never do, implementation details are just that.
>
> Sometimes you need to, even if you don't want to. Say you're 
> implementing a container, for simplicity let's say an Array!T 
> (akin to Vector from your automem library). Because it's D, the 
> author needs to be aware of GC implications. Namely, when 
> removing elements from the array, or reserving additional 
> storage, and `T` may have indirections, the Array should wipe 
> unused storage (or appropriate bits) to eliminate false 
> pointers. This isn't a part of public interface at all, but 
> still something that should be tested against.

This is more a comment on the lack of druntime's lack of 
testability than anything else. I'm still annoyed (and slightly 
worried) that I can't test that I'm telling the GC what I'm 
supposed to.