Any future plans for resolving the ambiguity between arguments belonging to an attribute vs. a closure?

Development Compiler
1

Hi, I came across the discussion about the ambiguity between whether arguments belong to an attribute or a closure in this PR

My thought was that we should stage this as a diagnostic and then we can change the parsing behavior to unambiguously parse (a, b) as the closure’s parameters in a year or so.

Overview of the problem

// We expect (a, b) to be parsed as the closure's parameters,
// but currently (Swift 6.1), it is parsed as an argument to the attribute
// (and results in an error about missing closure parameters).
let closure: @MainActor (Int, Int) -> Void = { @MainActor (a, b) in ... }
// 🔴 Contextual type for closure argument list expects 2 arguments, which cannot be implicitly ignored
// 🔴 Extraneous whitespace between attribute name and '(' <- this diagnostic was added in the PR

Is there any concrete plan or timeline for when this ambiguity will be resolved?

I'm hoping for a fix like in my draft PR: don't parse arguments of attribute if there are whitespaces between name and lparen in custom attribute by kntkymt · Pull Request #1 · kntkymt/swift · GitHub (treating args as closure’s args if there are whitespaces between attribute name and following lparen)

2 Likes