D language supports shadowing members, where the shadowed member has same name and different type on same type.

Why is this enabled, and when should one use this advanced technique?

On Friday, 8 August 2025 at 23:52:31 UTC, Brother Bill wrote:

On Friday, 8 August 2025 at 23:52:31 UTC, Brother Bill wrote:

Overload rules are probably more fundamental then your thinking. Theres a core idea that hidden under the name "overload set".

import std;
void bar(int){"int".writeln;}
void bar(float){"float".writeln;}
ref bar(bool b){
  bool bar;
}
alias foo=bar;

void foobar(alias A)(){
  A(1);
  A(13.37);
  A=true;
}
unittest{
  foobar!foo;
}

whats foo? unhelpfully its an "overload set"; I have not seen a good explanation for what it is.

On Friday, 8 August 2025 at 23:52:31 UTC, Brother Bill wrote:

That's not considered as shadowing as you can distinguish the two members using a qualified access chain.

class A {int m = 1;}
class B.A {float m;}

assert((new B).A.m == 1);

On Saturday, 9 August 2025 at 01:33:03 UTC, user1234 wrote:

class A {int m = 1;}
class B.A {float m;}

assert((new B).A.m == 1);

I understand that members of various levels can be distinguished.
What I don't understand is why one would use this technique.

On Saturday, 9 August 2025 at 04:02:03 UTC, Brother Bill wrote:

class A {int m = 1;}
class B.A {float m;}

assert((new B).A.m == 1);

As a regular user you probably don't need it.

I use it for meta programming and some quirky C++ interop where things can't be directly translated, for example when mixing virtual and non-virtual functions in C++ base/children classes (can't overload by virtual in D).
This is just one of examples on learn forum some time ago that shows some quirks of c++ interop and how overload set is used to fix it.
https://forum.dlang.org/post/zmzzissfeqoqxojgprxy@forum.dlang.org

Basically same approach can be used for example to nativize API of C-style OOP like one used in GTK to make it feel more D.
That's being said, it is mostly for making API look nice to the users.

On Saturday, 9 August 2025 at 04:02:03 UTC, Brother Bill wrote:

I skipped that part of the question because I thought that the fact that it's not a shadowing case invalidates it.

To be frank the only time I've ever used that was with OOP and when a derived class introduced a derived instance of another class type:

class Declaration {}
class StructDeclaration : Declaration {}

class TypeDeclaration {
    Declaration d;
    this(Declaration d){
        this.d = d;
    }
}

class TypeStruct : TypeDeclaration {
    StructDeclaration d;
    this(StructDeclaration d){
        this.d = d;
        super(d);
    }
}

So that whenever you work with a TypeDeclared or one of his derived class, you known that d is of the corresponding Type with a corresponding level of derivation.

Obviously in this case a system of overlapped field would have made more sense but that does not exist in D (never seen that elsewhere either btw).