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

[Neia Neutuladh]

On Sun, 28 Oct 2018 04:38:53 +0000, unprotected-entity wrote:
> In C++/Java/C#, x is private to C, as you would expect, since it was
> declared private to C.

Let's look at a few languages and see exactly what they do.

In C++, x is private to C and any friend types or functions.

In C#, x is private to C (but can be accessed via reflection).

In D, x is private to C and any types or functions defined in the same 
module.

In Dart, _x is private to C.

In Delphi, x is private to C.

In Go, x is private to that source file. (I believe. It might be private 
to that directory. I don't care enough to check.)

In Java, x is private to C, all types in which C is nested, and all types 
nested in any of those types. It can also be accessed via reflection.

In Javascript, x is public. In order to make a private-style variable, you 
need to use a local variable in the type's constructor. This prevents you 
from using method syntax in methods referring to that variable; you need 
to assign closures to fields instead.

In Lua, x is public (or you use the Javascript workaround).

In Perl, x is public.

In Python, __x doesn't exist; it's syntactic sugar for _C__x. _C__x is 
public.

In Ruby, @x is protected (but can be accessed via reflection).

In Rust, x is private to the module.

In Swift, there are different versions of 'private' for private-to-type and 
private-to-source-file.

So no, there is no one standard way of doing things that D violates. D 
uses a system that's tied for second place behind not having private 
variables at all.