Toughts on alias this. (implict converstion in general)

[12345swordy]

On Wednesday, 13 May 2020 at 22:38:26 UTC, 12345swordy wrote:
> On Wednesday, 13 May 2020 at 22:27:00 UTC, Timon Gehr wrote:
>> On 13.05.20 23:06, 12345swordy wrote:
>>> As I am working on the tuple dip and porting Timon Gehr work, 
>>> I noticed that there is a section on alias this which got me 
>>> thinking. I really don't want the ability to alias this the 
>>> tuple itself as that could cause problems in the future. It 
>>> seems that Walter share the same negative sentiment regarding 
>>> alias this. We could introduce implicit constructors for 
>>> structs/classes for rvalues and implicitOP for lvalues by 
>>> having structs copy it and having classes GC allocate it. 
>>> That way we could introduce implicit conversion without 
>>> having the rest of the baggage that alias this 
>>> introduce.(Credit for manu for coming up the idea). Of course 
>>> this is all opt-in from the developer side to prevent 
>>> unintentional function design.
>>> 
>>> 
>>> - Alex
>>
>> Do you understand how std.typecons.Tuple works?
>> Do you understand _why_ there is a section in the DIP related 
>> to alias this?
> From my understanding std.typecons.Tuple is a struct that is 
> generated from templates. Though I don't understand why there 
> is a section for alias this though. For the types themselves in 
> the tuple? Sure.
> For the tuple itself? I literally have no idea.
>
> I was planing to post the first draft and ping you on this some 
> time in the future.
>
> -Alex
Ok I take back what I had said about the types in the tuple, 
because it quite apparent that it is a lot more difficult then 
expected.

Let type a, b, x, y exist

x contains alias this of a
y contains alias this of b

function f() exist with two overloads.

f((a, y)) takes the tuple of a and y
f((x, b)) takes the tuple of x and b

you pass tuple (x, y) to function f.

What exact function does it call in this case?
To be frank: I have no idea in this case.