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

[Stanislav Blinov]

On Friday, 26 October 2018 at 19:27:11 UTC, 12345swordy wrote:
> On Friday, 26 October 2018 at 18:45:32 UTC, Stanislav Blinov 
> wrote:
>> On Friday, 26 October 2018 at 18:16:38 UTC, 12345swordy wrote:
>>> Mike Parker told me that this is intentional and not a bug.
>>
>> It's not a bug.
> Is this really necessarily?

Yes. It's so that you don't solely blame Mike for your 
misunderstanding of the language. Now you can blame me if you 
want.

>> Why "however"?
>
> Class private member variables are behaving like they protected 
> class protected when creating derived class in the same module.

Which is a problem because?..

>> There's no contradiction. Within a module, you have access to 
>> everything.
> This is about inheritance not encapsulation. You shouldn't be 
> accessing doors when they shouldn't exist in the first place.

So... use the language as intended and don't put things that 
absolutely must not access private data into the same module. 
Doors expunged.

>>> Why private member variables behave like protected member 
>>> variables in the same module?
>> Because according to the spec, "Symbols with private 
>> visibility can only be accessed from within the same module."
> Was referring to class member variables not the module member 
> variables.

Class is within a module. It's members are within a module. Ergo, 
they're accessible even when private. Again, there's no 
contradiction at all.

>> It's *your* module.
> There are cases where is not necessarily "my" module but rather 
> it is the "team" module.

So? As long as the "team" uses the same language, all it's 
members should understand what "private" means *in that language*.

>>There's absolutely no need for artificial restrictions.
> Nonsense, @safe and @nogc are artificial restrictions. Code 
> discipline is good behavior, even for yourself.

1) @safe and @nogc have nothing to do with visibility.
2) Exactly my point.

>> To keep your desk drawer tidy you, well, keep it tidy, not 
>> mess it up and throw away the key.

> How I organized my desk drawer is up to me though.

Yep, which is exactly why the language lets you do whatever you 
want with symbols inside a module.

>>> Can you explain your thought process when it comes to this 
>>> design decision Walter Bright?
>> I'm sure Walter should be honored to be graced with such an 
>> eloquent inquiry.
> Is that sarcasm?

No, no, I really think Walter owes you an explanation as to why 
your assumptions about the language are faulty.

...Of course it was sarcasm. Sigh.