Struct inheritance

[user1234]

On Friday, 20 September 2024 at 15:23:25 UTC, Nick Treleaven 
wrote:
> On Thursday, 19 September 2024 at 19:04:40 UTC, Richard (Rikki) 
> Andrew Cattermole wrote:
>> On 20/09/2024 6:57 AM, Nick Treleaven wrote:
>>> This seems like |alias this| in disguise.
>>
>> The problem with alias this, is it is not defined as the 
>> fallback when nothing else in the hierarchy matches.
>>
>> Here it is better defined, opDispatch should only be chosen 
>> after exhausting the hierarchy, both in classes and structs.
>
> I don't see why you want to overload opDispatch to do 
> subtyping. It doesn't seem related to existing opDispatch.
>
>> Eliminating the issues with alias this from the design.
>>
>> We can further restrict it, to only support the parent most 
>> type in the hierarchy or only one in the hierarchy. In effect 
>> it allows adding a new parent to the top of the hierarchy.
>
> I don't think we need to restrict its capabilities, we just 
> need another syntax for it so we can fix the semantics. If 
> anything I'd like to increase its capabilities. It could be 
> defined as a template method and instantiated with the type of 
> the expected result, and the constraint determines whether the 
> conversion is enabled for that type.
> [...]

It's basically the same as `opCast` but called without `cast`. A 
long time ago this was discussed, (we called that 
opImpcConvRight). That thing would work but to fix `alias this` 
problems then the users need to overload much more operators, and 
that becomes unatural to use, i.e vs `alias this` which works 
more naturally. Fact is there are plenty of situation where 
implicit convs are not tried but you want that new op to be 
tried. Basically that's the exact same situations where currently 
the compiler has to try if `alias this` is possible.