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

[unprotected-entity]

On Saturday, 27 October 2018 at 18:06:36 UTC, Atila Neves wrote:
> On Saturday, 27 October 2018 at 15:24:19 UTC, 
> unprotected-entity wrote:
>> On Saturday, 27 October 2018 at 14:20:10 UTC, Steven 
>> Schveighoffer wrote:
>>>
>>> If b didn't have an `x` in it, then how would this work?
>>>
>>
>> Only in D, does b have x in it.
>>
>> In C++, Java and C#, b does *not* have x in it.
>
> It might be that you're confusing "have" to mean "has access". 
> In other languages b doesn't have access to x, but it most 
> definitely has an x inside of it.

In C++/Java/C#, x is private to C, as you would expect, since it 
was declared private to C.

In D, it's not private to C, or anything else in the same module.

I know the reasoning behind this, but it's just awful, and 
invites bugs into your code.

oh... so you accidently typed b.x++ in main().. or someother code 
outside of the class), instead of b.increment() ...well...to bad.

Yes.. it's an old discussion, I know..but an unprotected entity 
is a useless programming construct, and will invite bugs into 
your program.