Bug 2631 – alias symbol this;

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.

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

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

(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

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

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

(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

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

This became a cool feature.

(In reply to comment #8) > This became a cool feature. And then became a closed enhancement request