Yes, and the reason they are is that a new user doesn't really understand what that closure is doing there: the space between the function root name and the closure doesn't signal clearly that the closure is a parameter of the function. That's why newcomers find trailing closures confusing. This proposal will make them less confusing. If the argument to focus on here is "clarity for newcomers", I can assure you that requiring labels for all trailing closures will be by far the best way for newcomers to understand what's going on.
Of the examples in you comparison, the following:
thing.bind
get: { otherThing }
set: { otherThing = $0 }
seems to me the most clear by far. It's the only one where the symmetry of arguments, related to the nature of the bind function, is spelled out the best, and will probably be the easiest for newcomers to undestand.
This, conversely, will probably be terrible for newcomers:
thing.bind(get:) { otherThing }
set: { otherThing = $0 }
Other than being ugly, a newcomer will probably not understand at all what that (get:) is: a lot of Swift is structured to read like natural language, and this doesn't; wrapping the parameter label in parentheses next to a root function name is a language detail that many people, even long-term Swift users, don't know.
It's not much of an advantage if some syntax already exists in the language, but it's ugly and hard to parse. SE-279 introduced a new, pretty heavy syntactic element, that is, an argument label (with :, that's what means in Swift "argument label", the same that would mean for the first closure) for all closures but the first: adding it to the first is really just an extension of that proposal.
I personally consider this super-clear and definitely Swift-like:
myArray.first where: { $0 < 5 }
the reason being the colon after where: the colon in Swift, in the context of calling a function, is used to indicate argument labels, so this reads as an argument label with its argument but without surrounding parentheses. Are surrounding parentheses "Swift-like"? Well, it depends: on function calls, yes, but on statements like if and switch they're not, so the language didn't really make its mind for now. A good thing about SE-279 and this proposal is that they move the language in a direction of less parentheses, and I couldn't be happier: most of the time they're redundant, make readability worse and represent unneeded additional syntactic burden where what's going on is easily understandable from the context.
On the other hand, something like this would be problematic:
thing.bind
get: { otherThing }
set: { otherThing = $0 }
myArray.first
where: { $0 < 5 }
With no indentation and no spaces, this would be hard to parse, but this is really a styleguide problem, and it's mostly the same right now: even this is bad:
thing.bind(
get: { otherThing },
set: { otherThing = $0 })
myArray.first(
where: { $0 < 5 })
the additional final character (being (, ) or ,) doesn't improve the situation. A proper formatting of the whole thing would be:
thing.bind(
get: { otherThing },
set: { otherThing = $0 }
)
myArray.first(
where: { $0 < 5 }
)
Here's the same without extra redundant characters:
thing.bind
get: { otherThing }
set: { otherThing = $0 }
myArray.first
where: { $0 < 5 }
It reads better, no context is lost, and there's no unneeded characters. Notice that this could be the same also for regular parameters, not just trailing closures, but the latter allow for an easier parsing thanks to the curly braces.
]