Add BlockStatement to TemplateSingleArgument

[dlangBugzillaToGithub]

Vladimir Panteleev (@CyberShadow) reported this on 2014-02-04T03:03:40Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=12074

Description

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.

[dlangBugzillaToGithub]

dlang-bugzilla (@CyberShadow) commented on 2014-02-04T03:09:00Z

I see Kenji posted a patch in 2010 here:

http://d.hatena.ne.jp/khara_9rnsr/20100927/1285572362

[dlangBugzillaToGithub]

dlang-bugzilla (@CyberShadow) commented on 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.

[dlangBugzillaToGithub]

b2.temp commented on 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 ?

[dlangBugzillaToGithub]

dlang-bugzilla (@CyberShadow) commented on 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.