Comment #0 by dlang-bugzilla — 2014-02-23T01:49:08Z
///////////////////// 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
}
/////////////////////////////////////////////////
Comment #1 by dlang-bugzilla — 2014-02-23T01:51:47Z
Actually, this refers to all non-static methods, not just properties.
Comment #2 by dlang-bugzilla — 2014-03-02T12:32:27Z
(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.
Comment #4 by k.hara.pg — 2016-03-15T15:35:12Z
(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?
Comment #5 by dlang-bugzilla — 2016-03-15T16:19:13Z
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.
Comment #6 by robert.schadek — 2024-12-13T18:17:21Z