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

[12345swordy]

On Friday, 26 October 2018 at 20:52:38 UTC, Stanislav Blinov 
wrote:
> 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.
>
What is that all about!? Are you type of guy who like get into 
fights?
>>> 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?..
It's a problem as we have the protected keyword already! There is 
no reason for private to act it's protected in the same module!
If you want child to inherent your private member variables then 
used protected.
Otherwise private should mean that belongs to class A and only to 
class A. If you wanted your child class to inherent private 
member variables only in a module then we need a new access 
attribute to avoid unwanted pitfuls.

>>> 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
That is a huge moot point itself that should belong it own thread.
> and don't put things that  absolutely must not access private 
> data into the  > same module.
I repeat:
This is about inheritance not encapsulation. You shouldn't be
accessing doors when they shouldn't exist in the first place.

You are debunking a straw man.


> 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.

Again you are debunking a straw man.


> 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
You didn't say visibility, you said "artificial restrictions"

>>> 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.
>
Really? Then why I can't get rid private member variables that 
class B inherent from class A that is marked "private".
Do I have to mark them delete every time I inherent?

>
> 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.
Tone of voice do not transfer over the internet.