///////////////////// test.d //////////////////// import std.stdio; static template T(alias a) { void foo() { writeln(a); } } struct S { int i = 1; @property int p() { return 2; } alias ti = T!i; // OK alias tp = T!p; // Error } ///////////////////////////////////////////////// The compiler rejects the above code, with the error: test.d(5,23): Error: need 'this' for 'p' of type '@property int()' The problem can be worked around by adding an anchor parameter to the template. This correctly sets the "this" type for the template: //////////////////// test2.d //////////////////// static template T(alias a, alias anchor = Object) { void foo() { writeln(a); } } struct S { int i = 1; @property int p() { return 2; } alias ti = T!(i); // bound to S implicitly alias tp = T!(p, i); // bound to S via anchor } /////////////////////////////////////////////////
Actually, this refers to all non-static methods, not just properties.
https://github.com/D-Programming-Language/dmd/pull/3345
(In reply to Vladimir Panteleev from comment #0) > ///////////////////// test.d //////////////////// > import std.stdio; > > static template T(alias a) > { > void foo() { writeln(a); } > } > > struct S > { > int i = 1; > @property int p() { return 2; } > > alias ti = T!i; // OK > alias tp = T!p; // Error > } > ///////////////////////////////////////////////// > > The compiler rejects the above code, with the error: > test.d(5,23): Error: need 'this' for 'p' of type '@property int()' From the long discussion in issue 11946, the static template T cannot get any context even if the aliased symbol a is an instance member.
(In reply to Kenji Hara from comment #3) > From the long discussion in issue 11946, the static template T cannot get > any context even if the aliased symbol a is an instance member. Or... am I misunderstanding something?
Well, for one thing, there is the inconsistence - if fields bind context, why don't methods? In much broader terms, I really really wish we'd have explicit control over alias context binding, at the instantiation site. Template aliases can allow for some very powerful things with a few small tweaks. I've written a serialization framework with almost zero overhead which depends on the compiler patches I wrote: https://github.com/CyberShadow/ae/tree/master/utils/serialization However, the compiler patches were not accepted so this is mostly defunct. For personal use I'm still using a patched compiler with PR #3884 reverted. I realize this is hypocritical of me because I argued a lot in favor of that PR (as a fix to code breakage), however I have come to depend on the behavior that PR reverted in my allocators library. I would like to some day make a case for these small language improvements, but I feel like it would be more wasted work. I almost went mad just from attempting to implement __traits(child) correctly.
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18780 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB