On 4/2/21 11:42 AM, Adam D. Ruppe wrote:
> On Friday, 2 April 2021 at 15:35:03 UTC, mw wrote:
>> Is this a compiler bug, or by language design?
> 
> https://dlang.org/spec/attribute.html#visibility_attributes
> 
> "Symbols with private visibility can only be accessed from within the same module. Private member functions are implicitly final and cannot be overridden."
> 
> 
> Key word there being "module".

To exapand on this, this is D's answer to "friend" functions in C++.

-Steve

On Friday, 2 April 2021 at 15:56:43 UTC, Steven Schveighoffer wrote:
> On 4/2/21 11:42 AM, Adam D. Ruppe wrote:
>> On Friday, 2 April 2021 at 15:35:03 UTC, mw wrote:
>>> Is this a compiler bug, or by language design?
>> 
>> https://dlang.org/spec/attribute.html#visibility_attributes
>> 
>> "Symbols with private visibility can only be accessed from within the same module. Private member functions are implicitly final and cannot be overridden."
>> 
>> 
>> Key word there being "module".
>
> To exapand on this, this is D's answer to "friend" functions in C++.
>
> -Steve

We could introduce "this private", via DIP, but there isn't much motivation behind it as the workaround is define the struct in one module and define the function in another function. The private behave differently from other languages does not seemed to effect many people here.

-Alex

On Friday, 2 April 2021 at 18:33:35 UTC, 12345swordy wrote:
> On Friday, 2 April 2021 at 15:56:43 UTC, Steven Schveighoffer wrote:
>> On 4/2/21 11:42 AM, Adam D. Ruppe wrote:
>>> On Friday, 2 April 2021 at 15:35:03 UTC, mw wrote:
>>>> Is this a compiler bug, or by language design?
>>> 
>>> https://dlang.org/spec/attribute.html#visibility_attributes
>>> 
>>> "Symbols with private visibility can only be accessed from within the same module. Private member functions are implicitly final and cannot be overridden."
>>> 
>>> 
>>> Key word there being "module".
>>
>> To exapand on this, this is D's answer to "friend" functions in C++.
>>
>> -Steve
>
> We could introduce "this private", via DIP, but there isn't much motivation behind it as the workaround is define the struct in one module and define the function in another function. The private behave differently from other languages does not seemed to effect many people here.
>
> -Alex

I meant "in another module."

-Alex

On Friday, 2 April 2021 at 18:33:35 UTC, 12345swordy wrote:
> The private behave differently from other languages does not seemed to effect many people here.

AFAIK, it copies java.

On 2/4/21 23:41, Kagamin wrote:
> On Friday, 2 April 2021 at 18:33:35 UTC, 12345swordy wrote:
>> The private behave differently from other languages does not seemed to effect many people here.
> 
> AFAIK, it copies java.

Actually no. In java, according to the spec, the encapsulation unit is the "top-level" class. The java spec says[1]:

> Otherwise, the member or constructor is declared private. Access is permitted only when the access occurs from within the body of the top level class or interface that encloses the declaration of the member or constructor.

Usually this is translated into once class per file (module, in D), because you can only have one *public* top-level class per file, (module, in D), and there aren't any free functions, so the question just doesn't usually arise.

However, although not really recommended and seldom used, you can actually have multiple classes per file, as long as only one of them is public (the rest needn't be "private", can be "package"). In this case encapsulation works between classes. This is actually quite inconsistent and can lead to weird behavior like this:

```java
public class A {
    static private class InnerA {
        private int a = 0;
    }
    static private class InnerB {
        void foo(InnerA a) {
            // InnerA can access InnerB private members
            a.a = 1;
        }
    }

    void foo(B b) {
        // But A can't acces B private members
        b.b = 1; // A.java:14: error: b has private access in B
    }
}

class B {
    private int b = 0;
}
```

So all in all, D's behavior is at least consistent and something one can get easily used to.

[1]: https://docs.oracle.com/javase/specs/jls/se16/html/jls-6.html#jls-6.6.1

On the other hand C# implements strict access control. I once needed to give access to an otherwise private member of inner class to outer class and had to declare it internal, which is a bit too broad access level, but there's no other way to solve this task in C# due to that strict access control.