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.


-- 

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


-- 

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;".


-- 

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


-- 

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.


-- 

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.


-- 

> 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

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


-- 

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


-- 

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


--- Comment #9 from yebblies <yebblies@gmail.com> 2011-06-15 23:13:29 PDT ---
(In reply to comment #8)
> 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: -------