Lambda as UDA is valid but spec requires brackets

[dlangBugzillaToGithub]

Richard (Rikki) Andrew Cattermole reported this on 2024-01-20T01:25:08Z

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

CC List

Description

From: https://forum.dlang.org/post/hnjcuvuzytbuvgfdhfkd@forum.dlang.org

The lambda here is valid, even though it is not in a brackets.

```d
@a=>7 int b;
pragma(msg, __traits(getAttributes, b)); // AliasSeq!((a) => 7)
```

Should only be supported (according to specification):

```d
@(a=>7) int b;
pragma(msg, __traits(getAttributes, b)); // AliasSeq!((a) => 7)
```

Clarification or a compiler bug fix is needed.

[dlangBugzillaToGithub]

hsteoh commented on 2024-01-20T01:34:51Z

I'm inclined to say that parentheses should be required, for consistency with the single-token requirement on unparenthesized UDAs. (Cf also binary `!` syntax, where the unparenthesized version also requires exactly 1 token, and in all other cases parentheses are required.)

[pbackus]

Allowing this breaks shortened function bodies:

struct UDA {}

int foo() @UDA => 123;

void main()
{
    assert(foo() == 123);
    // error: undefined reference to '_D9onlineapp3fooFZi'
}

In the above code, => 123 should be parsed as the function body of foo, but it is instead parsed as part of the attribute @(UDA => 123).

[zero-vector]

From the linked forum discussion (https://forum.dlang.org/post/hnjcuvuzytbuvgfdhfkd@forum.dlang.org)

Generally we consider the implementation to win on differences between the compiler and specification for issues such as this.
Given that it does not appear to be harmful, no need to change the compiler :)

But IMHO the implementation is harmful, it prevents use of Shortened Function Declarations. And so the severity of the bug should be bumped, to get some attention.

It should be decided if it is a spec bug, or parser bug and handled accordingly.