www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Toughts on alias this. (implict converstion in general)

reply 12345swordy <alexanderheistermann gmail.com> writes:
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
May 13 2020
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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?
May 13 2020
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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
May 13 2020
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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.
May 13 2020
parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
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
May 14 2020