www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - alias this

reply "js.mdnq" <js_adddot+mdng gmail.com> writes:
I've seen this technique pop up in several things and I'm curious 
to what it is/how it's used?

alias t this;

does what? It seems like it's used as a way to "trick" the 
compiler into doing some cool/useful things?
Nov 30 2012
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/30/12, js.mdnq <js_adddot+mdng gmail.com> wrote:

 alias t this;


This should explain: http://dlang.org/class.html#AliasThis
Nov 30 2012
parent reply "js.mdnq" <js_adddot+mdng gmail.com> writes:
On Friday, 30 November 2012 at 14:02:42 UTC, Andrej Mitrovic 
wrote:

 On 11/30/12, js.mdnq <js_adddot+mdng gmail.com> wrote:

 alias t this;


 This should explain: http://dlang.org/class.html#AliasThis


Thanks, I'm sure I saw that at some point but I guess it just 
didn't sink in. This seems really cool and might solve a problem 
I had much more elegantly...
Nov 30 2012
parent reply "Rob T" <rob ucora.com> writes:
On Friday, 30 November 2012 at 14:14:36 UTC, js.mdnq wrote:

 On Friday, 30 November 2012 at 14:02:42 UTC, Andrej Mitrovic 
 wrote:

 On 11/30/12, js.mdnq <js_adddot+mdng gmail.com> wrote:

 alias t this;


 This should explain: http://dlang.org/class.html#AliasThis


 Thanks, I'm sure I saw that at some point but I guess it just 
 didn't sink in. This seems really cool and might solve a 
 problem I had much more elegantly...


Note that multiple alias this declarations are slated to be 
allowed, but have not yet been implemented:

-----------
Multiple AliasThis are allowed. For implicit conversions and 
forwarded lookups, all AliasThis declarations are attempted; if 
more than one AliasThis is eligible, the ambiguity is disallowed 
by raising an error. Note: Multiple AliasThis is currently 
unimplemented.
-----------
Nov 30 2012
parent reply "js.mdnq" <js_adddot+mdng gmail.com> writes:
On Friday, 30 November 2012 at 21:46:47 UTC, Rob T wrote:

 On Friday, 30 November 2012 at 14:14:36 UTC, js.mdnq wrote:

 On Friday, 30 November 2012 at 14:02:42 UTC, Andrej Mitrovic 
 wrote:

 On 11/30/12, js.mdnq <js_adddot+mdng gmail.com> wrote:

 alias t this;


 This should explain: http://dlang.org/class.html#AliasThis


 Thanks, I'm sure I saw that at some point but I guess it just 
 didn't sink in. This seems really cool and might solve a 
 problem I had much more elegantly...


 Note that multiple alias this declarations are slated to be 
 allowed, but have not yet been implemented:

 -----------
 Multiple AliasThis are allowed. For implicit conversions and 
 forwarded lookups, all AliasThis declarations are attempted; if 
 more than one AliasThis is eligible, the ambiguity is 
 disallowed by raising an error. Note: Multiple AliasThis is 
 currently unimplemented.
 -----------


I've seen that, how does it work?

struct A{
  Sometype val1;
  int val2;
  alias val1 this;
  alias val2 this; //???
}


How can A act both as Sometype and int? (at least without major 
issues) Does the compiler try to choose the appropriate alias 
depending on the lvalue or rvalue?
Nov 30 2012
next sibling parent "js.mdnq" <js_adddot+mdng gmail.com> writes:
I'm running into an issue of trying to get back the normal this 
pointer ;/

If I so `alias a this;` how do I get the pointer to the object 
back for other purposes?
Nov 30 2012
prev sibling parent reply "Rob T" <rob ucora.com> writes:
On Friday, 30 November 2012 at 23:11:28 UTC, js.mdnq wrote:

 I've seen that, how does it work?

 struct A{
  Sometype val1;
  int val2;
  alias val1 this;
  alias val2 this; //???
 }


 How can A act both as Sometype and int? (at least without major 
 issues) Does the compiler try to choose the appropriate alias 
 depending on the lvalue or rvalue?


If the D devs really do implement alias this fully, then the 
compiler will have to figure out which call to make based on both 
the return type and also the argument list. If a decision is 
ambiguous then a compiler error results. However to do alias this 
correctly and fully you'll have to effectively implement full 
signature overloading.

A few days back I started a thread asking why full function 
signature overloading was not being considered, which I think 
would be very useful to have, but it looked like the devs did not 
want to implement due to the complications involved (no other 
reason was given than that). IMHO they can do it and should do 
it, and will eventually have to do it, but we'll see. Also for 
some reason no one thought that implementing alias this fully 
would mean implementing full signature overloading, or at least 
implementing all of the things required to implement it.

--rt
Dec 01 2012
parent reply "js.mdnq" <js_adddot+mdng gmail.com> writes:
On Saturday, 1 December 2012 at 20:25:55 UTC, Rob T wrote:

 On Friday, 30 November 2012 at 23:11:28 UTC, js.mdnq wrote:

 I've seen that, how does it work?

 struct A{
 Sometype val1;
 int val2;
 alias val1 this;
 alias val2 this; //???
 }


 How can A act both as Sometype and int? (at least without 
 major issues) Does the compiler try to choose the appropriate 
 alias depending on the lvalue or rvalue?


 If the D devs really do implement alias this fully, then the 
 compiler will have to figure out which call to make based on 
 both the return type and also the argument list. If a decision 
 is ambiguous then a compiler error results. However to do alias 
 this correctly and fully you'll have to effectively implement 
 full signature overloading.

 A few days back I started a thread asking why full function 
 signature overloading was not being considered, which I think 
 would be very useful to have, but it looked like the devs did 
 not want to implement due to the complications involved (no 
 other reason was given than that). IMHO they can do it and 
 should do it, and will eventually have to do it, but we'll see. 
 Also for some reason no one thought that implementing alias 
 this fully would mean implementing full signature overloading, 
 or at least implementing all of the things required to 
 implement it.

 --rt


By full signature overloading I assuming you also the return type?

I don't see why it is so complicated in any case since a return 
type can just be seen as a ref argument:

int myfunc()

is basically the same as

void myfunc(ref int returnvalue)
Dec 01 2012
parent "Rob T" <rob ucora.com> writes:
On Saturday, 1 December 2012 at 21:33:15 UTC, js.mdnq wrote:

 By full signature overloading I assuming you also the return 
 type?


Correct.


 I don't see why it is so complicated in any case since a return 
 type can just be seen as a ref argument:

 int myfunc()

 is basically the same as

 void myfunc(ref int returnvalue)


The compiler has to check the return type already, so effectively 
it's already able to perform full function overloading, but 
instead of allowing it, the process is designed to prevent it, 
which I think is an unfortunate artificial limitation.

Here's the thread, if you want to read all about it

function overload on full signature?
http://forum.dlang.org/thread/tmqkejkytuitqhnemizz forum.dlang.org

Based on how the discussion went, my guess is that the problem 
has more to do with how the compiler is currently structured, 
making it more difficult than it should be, and that the D devs 
don't see enough benefit for implementing full function 
overloading at this time.

However at least some aspects of the problem will have to be 
tackled when attempting to fully implement "alias this", unless 
it's decided to keep things very limited and disallow multiple 
type conversions, but since that is something that C++ can do, I 
suspect it will at least be considered.

--rt
Dec 01 2012