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.

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.

On 20/09/2024 7:04 AM, 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.
> 
> 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 should mention that this aspect of the proposal while it add new semantics, doesn't have anything special related to the rules of acceptability of opDispatch itself.

We'll need to define how opDispatch works in the hierarchy. Otherwise we'll have come right back to the same set of issues as alias this has.

On 20/09/2024 10:14 PM, IchorDev wrote:
> On Thursday, 19 September 2024 at 15:56:06 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> As an idea this has come up in Razvan's DConf 2024 talk.
>>
>> 1. Support inheritance on struct, for other structs.
>> 2. ``opDispatch`` function, may work in place of ``alias this`` when no parent exists.
> 
> What about interfaces?

While I do want signatures which would fill this void, the purpose of this is to get rid of alias this which has some problematic behaviors in symbol lookup.

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. In effect, allowing multiple `alias this` with the semantics defined by the aggregate author.

On 21/09/2024 3:23 AM, Nick Treleaven wrote:
>     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. In effect, allowing multiple |alias this| with the semantics defined by the aggregate author.

Ok so basically implicit conversions with optional target type.

As long as it is defined as being last resort after looking up through the hierarchy, then that aspect I'm ok with. Child most definition only.

You'll need to convince Walter wrt. argument to parameter matching, and he has some strong feelings on this.

But as far as the syntax changes are concerned for no target type, I'm ok with that being swapped to, it'll give it somewhere to expand to in the future.