Mike Parker told me that this is intentional and not a bug. However according to the spec: "Symbols with private visibility can only be accessed from within the same module. Private member functions are implicitly final and cannot be overridden."
Why private member variables behave like protected member variables in the same module? Can you explain your thought process when it comes to this design decision Walter Bright? Is there no way to mark the private member variables as "final" in the same module?

-Alex

On Friday, 26 October 2018 at 18:16:38 UTC, 12345swordy wrote:
> Mike Parker told me that this is intentional and not a bug. However according to the spec: "Symbols with private visibility can only be accessed from within the same module. Private member functions are implicitly final and cannot be overridden."
> Why private member variables behave like protected member variables in the same module? Can you explain your thought process when it comes to this design decision Walter Bright? Is there no way to mark the private member variables as "final" in the same module?
>
> -Alex

*Private member variables in classes obviously

-Alex

On Friday, 26 October 2018 at 18:16:38 UTC, 12345swordy wrote:
> Why private member variables behave like protected member variables in the same module?

I don't understand, what do you mean?

On 10/26/18 2:16 PM, 12345swordy wrote:
> Mike Parker told me that this is intentional and not a bug. However according to the spec: "Symbols with private visibility can only be accessed from within the same module. Private member functions are implicitly final and cannot be overridden."
> Why private member variables behave like protected member variables in the same module? Can you explain your thought process when it comes to this design decision Walter Bright? Is there no way to mark the private member variables as "final" in the same module?

There's no such thing as "final" member variables.

private variables and functions are visible ONLY within the module. private *functions* are final, meaning derived types cannot override them (and they are not virtual).

-Steve

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.

> However according to the spec: "Symbols with private visibility can only be accessed from within the same module. Private member functions are implicitly final and cannot be overridden."

Why "however"? There's no contradiction. Within a module, you have access to everything.

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

It's *your* module. You already have access to it's implementation in it's entirety. There's absolutely no need for artificial restrictions. To keep your desk drawer tidy you, well, keep it tidy, not mess it up and throw away the key.

> 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 there no way to mark the private member variables as "final" in the same module?

No.

On Fri, 26 Oct 2018 18:16:38 +0000, 12345swordy wrote:
> Why private member variables behave like protected member variables in the same module? Can you explain your thought process when it comes to this design decision Walter Bright? Is there no way to mark the private member variables as "final" in the same module?
> 
> -Alex

D's `private` within a module is identical to Java's `private` within a class and its nested classes. The following is valid Java:

// Protections.java
public class Protections {
    private void foo() { System.out.println("foo"); }
    public static class Bar {
        public void foo(Protections p) { p.foo(); }
        private void bar() { System.out.println("bar"); }
    }
    public static class Baz {
        private void bar(Bar b) { b.bar(); }
    }
    public static void main(String[] args) {
        new Bar().foo(new Protections());
        new Baz().bar(new Bar());
    }
}

If you maintain a D module, you are expected to maintain the whole module, so you should be able to determine when it's valid to access a private member. And this is useful.

This is the same as Java's opinion that, if you wrote a class, you should be responsible its nested classes too, and vice versa, so you should be able to access private members across those classes. Also because it's useful.

C++ uses `friend` instead: you explicitly mark what other types and functions can use your private variables.

C# has stricter `private` like you're expecting. Python has a way to make it annoying to refer to a class member.

So there's no clear winning way of doing things. D has one way of working that's rather useful but somewhat surprising (probably largely because of Java programmers who aren't familiar with some aspects of Java, I'm guessing). The less surprising alternative stops you from doing some useful things.

On Friday, 26 October 2018 at 18:45:06 UTC, Steven Schveighoffer wrote:
> On 10/26/18 2:16 PM, 12345swordy wrote:
>> Mike Parker told me that this is intentional and not a bug. However according to the spec: "Symbols with private visibility can only be accessed from within the same module. Private member functions are implicitly final and cannot be overridden."
>> Why private member variables behave like protected member variables in the same module? Can you explain your thought process when it comes to this design decision Walter Bright? Is there no way to mark the private member variables as "final" in the same module?
>
> There's no such thing as "final" member variables.

I was referring to class member variables, not the module itself. Sorry I didn't clarify the first time. The lack of edit function makes things difficult for me.

On Friday, 26 October 2018 at 18:40:36 UTC, Adam D. Ruppe wrote:
> On Friday, 26 October 2018 at 18:16:38 UTC, 12345swordy wrote:
>> Why private member variables behave like protected member variables in the same module?
>
> I don't understand, what do you mean?

I am referring to the class private member variable.

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?

> Why "however"?

Class private member variables are behaving like they protected class protected when creating derived class in the same module.



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

>> 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.
> It's *your* module.
There are cases where is not necessarily "my" module but rather it is the "team" module.
>There's absolutely no need for
> artificial restrictions.
Nonsense, @safe and @nogc are artificial restrictions. Code discipline is good behavior, even for yourself.
> 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.
>> 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?

On Friday, 26 October 2018 at 18:57:00 UTC, Neia Neutuladh wrote:
> On Fri, 26 Oct 2018 18:16:38 +0000, 12345swordy wrote:
>> [...]
>
> D's `private` within a module is identical to Java's `private` within a class and its nested classes. The following is valid Java:
>
> [...]

Again I am referring to classes in the module not the module itself.