Shadowing member in inheritance hierarchy - why

[evilrat]

On Saturday, 9 August 2025 at 04:02:03 UTC, Brother Bill wrote:
> On Saturday, 9 August 2025 at 01:33:03 UTC, user1234 wrote:
>> On Friday, 8 August 2025 at 23:52:31 UTC, Brother Bill wrote:
>>> 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?
>>
>> That's not considered as shadowing as you can distinguish the 
>> two members using a qualified access chain.
>>
>> ```d
>> 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.

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.