My experience with C++ and the "friend" class concept is it is necessary for C++ because it has no notion of a module.

D is much simplified by making the module the fence for encapsulation. C++ favors a smaller number of large files, D is designed around a larger number of small files.

I understand that you don't prefer that approach, but I suspect if you've used "friend" classes much in C++ you'd change your mind. Most people find D's way a relief.

On Wednesday, 8 June 2022 at 18:53:35 UTC, Walter Bright wrote:
> My experience with C++ and the "friend" class concept is it is necessary for C++ because it has no notion of a module.
>
> D is much simplified by making the module the fence for encapsulation. C++ favors a smaller number of large files, D is designed around a larger number of small files.
>
> I understand that you don't prefer that approach, but I suspect if you've used "friend" classes much in C++ you'd change your mind. Most people find D's way a relief.

I think there are two sides of the coin.

Also I don't think it's necessarily that people have a problem with how D wants it, it's just that some of us would like the option to opt-out of it when needed.

On 6/8/2022 1:23 AM, Max Samukha wrote:
> Why is it less of an abomination?

Because "friend" classes are a mess. They can be spread all over your code.

Modules are physically co-located in the same file, making them easy to manage.

On Wednesday, 8 June 2022 at 19:12:33 UTC, bauss wrote:
> On Wednesday, 8 June 2022 at 18:53:35 UTC, Walter Bright wrote:
>> My experience with C++ and the "friend" class concept is it is necessary for C++ because it has no notion of a module.
>>
>> D is much simplified by making the module the fence for encapsulation. C++ favors a smaller number of large files, D is designed around a larger number of small files.
>>
>> I understand that you don't prefer that approach, but I suspect if you've used "friend" classes much in C++ you'd change your mind. Most people find D's way a relief.
>
> I think there are two sides of the coin.
>
> Also I don't think it's necessarily that people have a problem with how D wants it, it's just that some of us would like the option to opt-out of it when needed.

+1

why is so hard for people to get this point? I don't get it.

It seems like such a simple concept -> an option to have a member of a class that is private to that class.

C'mon everyone. It's simple to get your head around.

There is no part of this idea that requires anyone to change what they currently do in D.

It's @pure opt-in.

On Wednesday, 8 June 2022 at 00:12:28 UTC, forkit wrote:
> On Monday, 6 June 2022 at 11:45:31 UTC, Dom Disc wrote:
>> On Monday, 6 June 2022 at 02:35:11 UTC, forkit wrote:
>>> On Monday, 6 June 2022 at 01:23:41 UTC, forkit wrote:
>>>>
>>>
>>> when your boss isn't really your friend:
>>>
>>> // ----
>>>
>>> module test;
>>> @safe :
>>>
>>> class Employee
>>> {
>>> }
>>>
>>> class Boss
>>> {
>>> }
>>>
>> Now that is real nonsense! Why should those two classes ever be within the same file?!?
>>
>
> The two classes were clearly concocted for the example - actually, after a discussion with a friend about problems they were having with their boss - who pretended to be friend to them, until one day ....
>
> But that aside, it is often that one object cannot exist, unless the other object already exists.
>
> It's not unusual, to want to keep this code together - even, god forbid, in the same module!
>
>> Not everything is a friend - only what is in the same file!
>
> Precisely. That's my whole point. Everything in the same file is your friend. Although, that is not the actual problem, since friends are useful. The actual problem is there is 'no option to unfriend'.
>
> There are no encapsulated components in a module. The D language doesn't provide the means to do that. It's all just one big... thing.

interface Foo {
    int itWorks();

    static Foo _new() {
        static class PrivateFoo : Foo {
            int _b;
            override int itWorks() { return _b; }
        }
        auto pfoo = new PrivateFoo;
        pfoo._b = 42; //only accessible in this function scope
        return pfoo;
    }
}

int main() {
    auto foo = Foo._new;
    writeln(foo.itWorks);

    return 0;
}

On Wednesday, 8 June 2022 at 21:38:24 UTC, forkit wrote:

>
> why is so hard for people to get this point? I don't get it.
>
> It seems like such a simple concept -> an option to have a member of a class that is private to that class.
>
> C'mon everyone. It's simple to get your head around.
>
> There is no part of this idea that requires anyone to change what they currently do in D.
>
> It's @pure opt-in.

We get your point just fine. That's not where the pushback is coming from. Like I've already told you, any new language feature has to justify its existence. New features add complexity to the language implementation and the cognitive load. There has to be a compelling reason to add it. You haven't demonstrated one in this thread from what I've seen.

You can achieve what you want by splitting things out into separate files, and that's what you have to overcome in order to sell this idea. You keep insisting this isn't good enough, because even then one can always add something to a module that accesses private class members. But that's not really a compelling reason, because the solution to that exists: don't do it.

You keep mentioning Java. Every method in a Java class has access to private member variables, even when the intention is for only one method to modify each member variable. How do they handle it? By convention.

It's the exact same issue you're complaining about here. In D, that the functions access the private members can be outside of the brace closing the class definition makes no practical difference. If you move to class per file, you've solved your conceptual problem of encapsulation at the class boundary, and as long as you never add a function to the module that accesses those variables  from outside of the closing brace you're golden. But you still have to contend with multiple member functions having access to the private variables, so you still have to go by convention if you want to keep access to the minimum. Or should we also have a level of encapsulation to allow access only from a single function?

If you can demonstrate that the benefit of adding a new level of protection to the language outweighs the cost, then you'll have a leg to stand on. But it's a tough sell since we already have a way to handle it.

On Thursday, 9 June 2022 at 00:38:56 UTC, Mike Parker wrote:
>
> ...the solution to that exists: don't do it.

Mmm. Why didn't I think of that.

Now my problem has gone away.

On Thursday, 9 June 2022 at 00:38:56 UTC, Mike Parker wrote:
>
> We get your point just fine. That's not where the pushback is coming from. Like I've already told you, any new language feature has to justify its existence. New features add complexity to the language implementation and the cognitive load....

The cognitive load is put onto me, when I come to D.

That becasue the D module system decides my specification for me, by making private, public within the module.

I have no say in this, other than these 'work arounds' that you insist I follow - including the best one yet 'just don't do it'.

Work-arounds is not a feature that D should be proud of.

I do not have to make the case for there being a need to make a part of a specification of an abstraction, truly private to that abstraction. That argument has been made decades ago, and proven to be a valid, and a highly useful, and highly used, design feature - even more so, when the compiler is able to enforce those invariants, which D cannot do.

So without an 'option' like I've suggested, the actual 'cognitive load' is put on to those that come to D.

IMO, without justification.