[SE-0279] Add support for an unbraced syntax for multiple trailing closures #30916
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…c` and `initializeCallArguments`
Also extend returned object from simplify being an expression to `TrailingClosure` which has a label, label's source location and associated closure expression.
Accept trailing closures in following form:
```swift
foo {
<label-1>: { ... }
<label-2>: { ... }
...
<label-N>: { ... }
}
```
Consider each labeled block to be a regular argument to a call or subscript,
so the result of parser looks like this:
```swift
foo(<label-1>: { ... }, ..., <label-N>: { ... })
```
Note that in this example parens surrounding parameter list are implicit
and for the cases when they are given by the user e.g.
```swift
foo(bar) {
<label-1>: { ... }
...
}
```
location of `)` is changed to a location of `}` to make sure that call
"covers" all of the transformed arguments and parser result would look
like this:
```swift
foo(bar,
<label-1>: { ... }
)
```
Resolves: rdar://problem/59203764
…es block If block is not just a list of labeled closures produce a tailored diagnostic and skip over invalid code.
- Diagnose non-closure-literals after label + colon - Form a TupleExpr, rather than a ParenExpr for a single labelled trailing closure.
Resolves rdar://problem/60250267
Syntax like `foo { _: { ... } }` is going to be parsed as a single
trailing closure.
rdar://problem/59688477
that allows arbitrary `label: {}` suffixes after an initial
unlabeled closure.
Type-checking is not yet correct, as well as code-completion
and other kinds of tooling.
…closures. The current approach for type-checking single trailing closures is to scan backwards from the end of the parameter list, looking for something that can be passed a closure. This generalizes that to perform label-matching in reverse on any later trailing closures, then pick up from that point when trying to place the unlabeled trailing closure. The current approach is really not a good language rule, but changing it as much as we'd really like will require evolution approval and a source break, so we have to be cautious.
rintaro
reviewed
Apr 14, 2020
|
Moved branch to the swift repository to make collaboration easier. Re-opened as #31052. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements an alternative to the syntax proposed in SE-0279, allowing an initial unlabeled trailing closure to be followed by an arbitrary number of labeled-closure postfixes.