www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2631] New: alias symbol this;

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2631

           Summary: alias symbol this;
           Product: D
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: andrei metalanguage.com


Walter and I just discussed a potential solution for 2628 that would also take
care of other issues rather nicely. Aliasing a symbol to "this" would allow the
compiler to substitute this with this.symbol in contexts where lookup or type
conversions are attempted. This may obviate a need for opImplicitCast and would
also serve as implementation inheritance and others.

Example:

struct Tuple!(T...)
{
    T data;
    alias data this;
}

Using t[0] for a tuple would first figure out opIndex is not defined by the
struct itself and then would substitute t[0] with t.data[0], which works.

struct X
{
    int x; 
    alias X x;
}

X a;
int b = a;
a = 42;

Neither use would compile, but the compiler substitutes:

int b = a.x;
a.x = 42;

so the code is working. If assignment is not desired:

struct S
{
    int _x;
    int x() { return x; }
    alias x this;
}

I'm posting this to open the floor for discussion.


-- 
Jan 28 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2631





------- Comment #1 from andrei metalanguage.com  2009-01-28 19:04 -------
Oh, and aliasing this should also nicely take care of the "inner name trick":

template Blah!(T) { alias T Blah; }

becomes

template Blah!(T) { alias T this; }

Much cleaner because it clarifies the intent and allows "one point of
renaming".


-- 
Jan 28 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2631





------- Comment #2 from jarrett.billingsley gmail.com  2009-01-28 19:23 -------
(In reply to comment #1)
 Oh, and aliasing this should also nicely take care of the "inner name trick":
 
 template Blah!(T) { alias T Blah; }
 
 becomes
 
 template Blah!(T) { alias T this; }
 
 Much cleaner because it clarifies the intent and allows "one point of
 renaming".
 

struct S { mixin Blah!(int); // what happens? } If 'this' always refers to the template, you can't do cute things like mixing in support for operations on values of type S. If 'this' refers to the template sometimes and to the enclosing scope in others, it's confusing. Then again, I can't tell you how often I've mistyped the name of a template in one of the nine places inside it, only to not find out until just the right conditions are met and then the compiler dies with a "voids have no value" error deep in some template instantiation which I can't figure out because it doesn't print a damned traceback. Sigh. Another problem with the "alias X this;" in templates is that it only works for aliases. You can't do "enum this = 5;". --
Jan 28 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2631





------- Comment #3 from andrei metalanguage.com  2009-01-28 19:39 -------
(In reply to comment #2)
 (In reply to comment #1)
 Oh, and aliasing this should also nicely take care of the "inner name trick":
 
 template Blah!(T) { alias T Blah; }
 
 becomes
 
 template Blah!(T) { alias T this; }
 
 Much cleaner because it clarifies the intent and allows "one point of
 renaming".
 

struct S { mixin Blah!(int); // what happens? } If 'this' always refers to the template, you can't do cute things like mixing in support for operations on values of type S. If 'this' refers to the template sometimes and to the enclosing scope in others, it's confusing.

I think that clips the toenails of my impetus.
 Then again, I can't tell you how often I've mistyped the name of a template in
 one of the nine places inside it, only to not find out until just the right
 conditions are met and then the compiler dies with a "voids have no value"
 error deep in some template instantiation which I can't figure out because it
 doesn't print a damned traceback.  Sigh.  
 
 Another problem with the "alias X this;" in templates is that it only works for
 aliases.  You can't do "enum this = 5;".
 

But you can do enum _zis = 5; alias this _zis; Andrei --
Jan 28 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2631





------- Comment #4 from jarrett.billingsley gmail.com  2009-01-28 19:56 -------
(In reply to comment #3)
 
 But you can do 
 
 enum _zis = 5;
 alias this _zis;

You mean "alias _zis this;" ;) Or, the compiler could allow aliasing expressions, and just auto-generate a dummy 'enum' symbol to alias. That is, alias 5 x; becomes enum _x_alias = 5; alias _x_alias x; I've wanted aliasing to work on both expressions and symbols for a while now. It would make some of my templates a lot simpler. --
Jan 28 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2631





------- Comment #5 from wbaxter gmail.com  2009-01-28 22:37 -------
(In reply to comment #2)
 (In reply to comment #1)
 Oh, and aliasing this should also nicely take care of the "inner name trick":
 
 template Blah!(T) { alias T Blah; }
 
 becomes
 
 template Blah!(T) { alias T this; }
 
 Much cleaner because it clarifies the intent and allows "one point of
 renaming".
 

struct S { mixin Blah!(int); // what happens? } If 'this' always refers to the template, you can't do cute things like mixing in support for operations on values of type S. If 'this' refers to the template sometimes and to the enclosing scope in others, it's confusing.

Could the usual scope differentiation syntax be used? alias T this; // I mean the template itself vs alias T .this; // I mean the this in the outer scope Granted the "scopes" aren't actually different when you mix-in a template, but I think the intent is clear enough. --
Jan 28 2009
prev sibling next sibling parent Brian <digitalmars brianguertin.com> writes:
 Could the usual scope differentiation syntax be used?
     alias T this; // I mean the template itself
 vs
     alias T .this; // I mean the this in the outer scope
 

would this make sense? alias T template; // I mean the template itself vs alias T this; // I mean the this in the outer scope
Jan 29 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2631





------- Comment #6 from site.puremagic.com brianguertin.com  2009-01-29 07:12
-------
(In reply to comment #5)
 (In reply to comment #2)
 (In reply to comment #1)
 Oh, and aliasing this should also nicely take care of the "inner name trick":
 
 template Blah!(T) { alias T Blah; }
 
 becomes
 
 template Blah!(T) { alias T this; }
 
 Much cleaner because it clarifies the intent and allows "one point of
 renaming".
 

struct S { mixin Blah!(int); // what happens? } If 'this' always refers to the template, you can't do cute things like mixing in support for operations on values of type S. If 'this' refers to the template sometimes and to the enclosing scope in others, it's confusing.

Could the usual scope differentiation syntax be used? alias T this; // I mean the template itself vs alias T .this; // I mean the this in the outer scope Granted the "scopes" aren't actually different when you mix-in a template, but I think the intent is clear enough.

would this make sense? alias T template; // I mean the template itself vs alias T this; // I mean the this in the outer scope --
Jan 29 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2631





------- Comment #7 from wbaxter gmail.com  2009-02-01 18:10 -------
(In reply to comment #6)

 
 would this make sense?
      alias T template; // I mean the template itself
  vs
      alias T this; // I mean the this in the outer scope
 

Ooh I like that. Or even: alias ..blahblah.. this(template); --
Feb 01 2009