Comment #0 by dlang-bugzilla — 2014-02-04T03:03:40Z
Currently, this is forbidden, both by the specification and implementation:
int call(alias fun)()
{
return fun();
}
int main()
{
return call!{ return 5; }();
}
It seems unambiguous, so I see no reason why it should not be allowed.
Perhaps the same idea applies to array/AA literals.
Comment #1 by dlang-bugzilla — 2014-02-04T03:09:00Z
Comment #2 by dlang-bugzilla — 2014-02-04T03:40:23Z
Kenji's patch is now outdated (not surprising). However, this very simple patch seems to work just fine:
diff --git a/src/parse.c b/src/parse.c
index 78a2356..088326d 100644
--- a/src/parse.c
+++ b/src/parse.c
@@ -2360,6 +2360,8 @@ Objects *Parser::parseTemplateArgument()
case TOKfuncstring:
case TOKprettyfunc:
case TOKthis:
+ case TOKlcurly:
+ case TOKlbracket:
{ // Template argument is an expression
Expression *ea = parsePrimaryExp();
tiargs->push(ea);
The original patch explicitly set the expression type to that of a function. This doesn't seem to be necessary, as the compiler now infers whether it is a function or delegate literal depending on whether statements refer to the literal's context.
Comment #3 by b2.temp — 2019-02-13T02:46:20Z
I like the idea but i see an ambiguity:
---
int call(alias fun)()
{
return fun();
}
int call(int value)()
{
return value+1;
}
void main()
{
call!{ return 0; }();
}
---
which overload is called ? The one that will doe CTFE and then call!0 or the other ?
Comment #4 by dlang-bugzilla — 2019-02-13T06:21:17Z
That is a semantic issue and completely orthogonal to this syntactic one. `call!({ return 0; })();` has the same issue as your example.
Comment #5 by robert.schadek — 2024-12-13T18:16:35Z