Something like ADL from C++?

[Richard (Rikki) Andrew Cattermole]

On 04/12/2024 7:22 AM, Derek Fawcus wrote:
> On Tuesday, 3 December 2024 at 17:35:36 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> This won't help you today but:
>>
>> 1. We are considering giving structs inheritance as part of replacing 
>> alias this.
>>
>> 2. I want a way to mark a method as 'reinterpreted' by the child 
>> class/struct. Specifically for serialization, removing the need for 
>> doing any lookups like this.
> 
> Please no.  Than then also makes the betterC subset too complex.
> 
> What facility of 'alias this' is it intended to preserve?  If only the 
> implicit conversion, then a new form of operator, or special named 
> member function strikes me as more suitable.
> 
>  From my perspective, one the the nice things about the class / strict 
> difference is that struct does not have any classful behaviour, i.e. it 
> has no inheritance.  If you add inheritance, that adds a thinking burden 
> when reading code, and essentially removes the difference between class 
> and struct, other than the implicit lock within classes.  I view the 
> 'reference type' thing as a rather trivial difference.
> 
> One could add something like the struct embedding of Go/Limbo/Alef/Ken-C 
> together with its implicit conversion for methods/functions.  The method 
> is then interpreted by the embedded element, but against the embedded 
> element, not the parent one.

My ideas post: 
https://forum.dlang.org/post/llqcjziyurwmyhzseonm@forum.dlang.org

The problem is alias this is too complex, and has introduced bugs that 
cannot be fixed, as it is relied upon.

Struct inheritance alone cannot fix it (note I did not originally 
propose this, that was Walter), my proposal is to add a way to reparent 
the parent most type, to replicate a lot of use cases of alias this 
without the bad behavior.

As a follow user of -betterC, I want to get full D classes working in 
it. Because there is absolutely no reason why they should not work 
(although such things as Object root class would not be present, 
therefore would need to be explicit).

This may seem unnecessary, but removing the coupling between the 
language implementation and druntime is important for pay as you go 
users, and with that custom runtimes. Which offers us greater portability.