Just so that I understand you correctly, would you want to have this feature 'as proposed' or the way I wrote it somewhere upthread?
More feedback on the proposal. I think maybe the name of the feature is a little bit misleading in case we really want to generalize it even further. It almost feels like a 'multi-line-trailing-parameter-list-closure'. The closest analogy here would be the multi-line string literal """ vs. the single-line string literal ". However this new syntax form can be used in combination with the standard parameter list, even though technically the standard parameter list can already be used throughout multiple lines.
The design for a 'multi-line-trailing-parameter-list-closure' is fairly straight forward.
If we had a function with the following signature:
func foo(
_ closure_1: () -> Void,
_ closure_2: () -> Void,
flag: Bool,
_: Int
) { ... }
We can transform the parameter list in a closure like syntax, but it would require you to write it throughout multiple lines. The trailing parameter list closure can start at any parameter point and therefore all of these forms would be valid.
let boolean = true
// if it's a single parameter in the
// trailing-parameter-list-closure
// then we don't need to force a new line
foo({ print(1) }, { print(2) }, flag: boolean) { 42 }
foo({ print(1) }, { print(2) }) {
flag: boolean
42
}
foo({ print(1) }) {
{ print(2) }
flag: boolean
42
}
// `foo() { ... }` would also be allowed,
// but we can omit `()`
foo {
{
print(1)
}
{ print(2) }
flag: boolean
42
}
Since the order of parameters is already strict, the labels shouldn't be required in theory, but from the call side they would help readability a lot.
The following forms are illegal, as the parameters should always start on a new line.
foo {
{ print(1) } { print(2) } flag: boolean 42
}
foo {
{ print(1) } {
print(2)
}
flag: boolean 42
}
The above examples are intentionally made not visually appealing, to simply show what we could potentially write. However I strongly think that we'd need that much flexibility to avoid edge-cases that would work better with such declarative-ish design, but communicate the correct use through good design guidelines.
By the way the above would also apply to init, but that's trivial.
