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

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?

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

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.

On Wednesday, 13 May 2020 at 22:53:47 UTC, 12345swordy wrote:
> 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.

It should match the behavior of classes:

class A {}
class B {}
class X : A {}
class Y : B {}

void fun(A a, Y y) {}
void fun(X x, B b) {}

unittest {
    // `fun` called with argument types `(X, Y)` matches both:
    //    `fun(A a, Y y)`
    // and:
    //    `fun(X x, B b)`
    fun(new X(), new Y());
}

--
  Simen