----- struct S { T getData(T)() { return T.init; } } alias getInt = S.getData!int; void main() { auto s = S(); int x = getInt(); // error: need 'this' (expected error) int y = s.getInt(); // error: not callable with S (hmm...) } ----- Currently it's not possible to easily create an alias of an aggregate template, forcing the user to always explicitly instantiate such a template at the call site. The workaround is to use a helper UFCS template that forwards to an internal template: ----- // workaround T getData(T)(S s) { return s.getDataImpl!T(); } struct S { T getDataImpl(T)() { return T.init; } } alias getInt = getData!int; void main() { auto s = S(); int x = s.getInt(); // ok // int y = getInt(); // errors, as it should } ----- But it would be much simpler if we could use the alias syntax for this. Since this might be a big enhancement it could use a forum discussion and maybe a DIP.
(In reply to comment #0) > Currently it's not possible to easily create an alias of an aggregate template, I'm not sure this has anything to do with templates? //---- struct S { int getData() { return int.init; } } alias getInt = S.getData; void main() { auto s = S(); int x = getInt(); // error: need 'this' (expected error) int y = s.getInt(); // error: not callable with S (hmm...) } //---- Same result.
(In reply to comment #1) > (In reply to comment #0) > > Currently it's not possible to easily create an alias of an aggregate template, > > I'm not sure this has anything to do with templates? Maybe a more generalized term like external member aliasing would be the actual feature. Then template support becomes automatic. If it were allowed then API writers wouldn't have to worry too much about adding convenience member aliases, since the users can do it themselves.
This is an invalid issue. Understanding how member function calls work makes this clear.