On Monday, 13 June 2022 at 12:03:10 UTC, Max Samukha wrote:

I honestly don't have a problem with module-level private, but I do have a problem with inconsistency and ignorance.

D argues so much about being module-level private, but it really isn't.

On Monday, 13 June 2022 at 12:03:10 UTC, Max Samukha wrote:

It can be fixed, but I personally prefer granting other entities «roles».

C++ friend-mechanism is one variant of granting "roles". For instance if you make the class MedicalRole a friend of the class Brain then you can make BrainSurgeon a subclass of MedicalRole which grants the BrainSurgeon access to the internals of Brains. Since C++ has multiple inheritance it follows that you can design your own role-granting regime in C++ if you want to.

(I personally prefer to only grant access to individual functions because it is tighter, but the concept of class based roles is easier to deal with when debugging/remodelling than the concept of package.)

On Monday, 13 June 2022 at 12:16:28 UTC, zjh wrote:

We should put all the modules in one file, so that there will be more friends!

On Monday, 13 June 2022 at 12:34:56 UTC, Ola Fosheim Grøstad wrote:

I guess it is worth adding that one weakness in C++ (and D) is that functions are not objects (in contrast to Beta). If functions were objects and if the called function could inspect the caller's object-type then you could design a much more advanced regime and create interesting novel framework-mechanisms using meta-programming.

On Monday, 13 June 2022 at 08:44:59 UTC, bauss wrote:

_c is accessible; you just have to use the syntax child.Foo._c to access it. This is documented in the language spec:

https://dlang.org/spec/class.html#fields

This is necessary because D allows you to define fields with the same name in a base class and its derived class; for example:

class Base
{
    int x = 123;
}

class Derived : Base
{
    int x = 456;
}

void main()
{
    auto instance = new Derived;
    assert(instance.x == 456);
    assert(instance.Base.x == 123);
}

On Monday, 13 June 2022 at 13:51:40 UTC, Paul Backus wrote:

This is horrifying, one of the darkest corner of D.

class Base
{
    int x = 123;
}

class Derived : Base
{
    int x = 456;
}

void main()
{
    auto instance = new Derived;
    assert(instance.x == 456);
    assert(instance.Base.x == 123);
}

On Monday, 13 June 2022 at 13:51:40 UTC, Paul Backus wrote:

Hardly necessary, C++ will error on this:

class A {
    int x=1;
    friend int main();
};

class B  : public  A {
    int x=4;
};


int main()
{
    B obj{};
    cout << obj.x;
}

But allow this:

class A {
    int x=1;
    friend int main();
};

class B  : public  A {
    int y=4;
};


int main()
{
    B obj{};
    cout << obj.x;
}

Of course, since C++ has multiple inheritance it has to deal with conflicts. D forbid it, although I guess you could argue that the subclass should not be affected by naming of fields in the superclass.

I still prefer that this is not allowed as shadowing in class hierarchies makes debugging so much more confusing.

On Monday, 13 June 2022 at 14:10:48 UTC, mw wrote:

Maybe it's no way to change the language now, but I need a warning message when this happens, in case I accidentally redefined such a field, at least with a compiler flag I can check it.

class Base
{
    int x = 123;
}

class Derived : Base
{
    int x = 456;
}

void main()
{
    auto instance = new Derived;
    assert(instance.x == 456);
    assert(instance.Base.x == 123);
}

On Monday, 13 June 2022 at 14:15:15 UTC, Ola Fosheim Grøstad wrote:

D could forbid it (since it is single inheritance).