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






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








 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










 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








 
 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 reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2631










 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
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






-------






 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 next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2631









 
 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
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2631


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |yebblies gmail.com
         Resolution|                            |FIXED





 This became a cool feature.


And then became a closed enhancement request

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 15 2011