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
next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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