SE-0279: Multiple Trailing Closures

Evolution Proposal Reviews
42

The difference is that if this proposal is accepted we will have a blessed form of syntactic sugar precisely for this case. It would be fighting the language not to take advantage of it. So I’m speculating that it would be broadly adopted throughout the community. Of course I could be wrong.

Perhaps. Of course there would still be endless formatting discussions. But I think in this very narrow case we wouldn’t see too many people arguing that the sugar should be avoided. It’s always possible I’m wrong about that.

The reason I thought this was worth mentioning is that the current syntax is awkward and therefore an area without a clear consensus.

43

There are no fewer round and curly braces required.

If commas are a problem here, why not everywhere else in parameter lists? Isn’t this an argument for approving SE-0257 instead?

6 Likes
44
  1. Yes, the commas
  2. The parameter labels will no longer align-left
  3. I don't like closing parens on their own line
  4. I don't like argument lists feeling like expressions.
  5. It's very contrary to Xcode's typical formatting. (which, like it or not, I'm kind of stuck with)
45
46

There are no fewer switches between round and curly braces.

Do you mean nesting? As in, your argument is that it is easier to parse nested pairs of punctuation that are the same than pairs that are different? Surely, you would agree that it is in fact the opposite.

2 Likes
47

How often do closures/parameters get moved around that this is a problem in practice? Wouldn't that mean that APIs have changed in breaking ways?

I think it's prioritizing the wrong thing to make decisions about the syntax of the language based on the ease with which it lets you rearrange blocks of code, especially when the proposed change introduces a redundant syntactical form that offers no clear advantage over the existing one except that it satisfies some users' personal style preferences.

But if we do want to factor that in, then @xwu is absolutely right that SE-0257 should be considered as well. However, I would prefer that we continue to require commas between arguments but also allow the trailing comma. I was originally against this when it was proposed, but I strongly prefer it to the alternative of eliminating all commas.

3 Likes
48

Never mind the moving statement, my point was that I have thought to myself, more than once, "I am displeased with the need for a comma here" for whatever reason. I didn't write them down each time, I will simply say that it happens enough that I know that I am in favor of this proposal.

4 Likes
49

IME moving doesn't happen often, but adding/removing does. Want to use a function with one closure? Use trailing closure syntax. Want to change it to use an overload that adds an additional closure?...now you'll need ~10 seconds of just moving code around.

50

This proposal changes nothing about the situation you described, because if you used trailing closure syntax originally, you would have to add the additional level of nesting and add the label to the closure argument in order to turn this:

foo(bar) {
  baz()
}

into

foo(bar) {
  first: { baz() }
  second: { someNewCode() }
}

In order to avoid the rearrangement of code, you would have needed to have the foresight to avoid using the singular trailing closure syntax to begin with:

foo(bar) {
  first: { baz() }
}

In which case, you could have done that all along with regular function call syntax as well:

foo(bar,
  first: { baz() }
)

And I'll continue to argue that saving 10 seconds to fix this isn't a reason to introduce confusion with a redundant syntax that doesn't actually change much.

7 Likes
51

Note that you would still need to move code around with this proposal, unless you intend to write all single trailing closures as { _: { ... } } just in case, which does not seem advisable (from a readability perspective if nothing else).

2 Likes
52

Without using it I think I would prefer that, but we'll see if/when I get that chance.

Anyway the difference is the complexity. To change it, you simply wrap it in curly braces and name it. Just like switching from a simple computed property to one with get/set.

It's also much more annoying when switching from this:

UIView.animate(withDuration: 0.4) {
    //animate
}

to this:

UIView.animate(withDuration: 0.4, animations: {
    //animate
}) {
    print($0)
}

Besides, IMO that argument amounts to "don't use trailing closures" which seems kind of irrelevant since they already exist and are used often.

53

I wouldn't, actually. Not in this case. I personally have a strong distaste for placing a ) on it's own line to close out an argument list that looks like a scope. Even }) is bothersome to me. Folks, in general–seem fine with it, but I really and truly don't. I prefer opening ( and the matching ) to be on the same line for an admittedly squishy definition of the "same line" (lining up left sides of arguments in an argument list works but the closing ) is on the same line as the last argument.)

EDIT: To expand on this, multiple closures–to me–establish a scope and curly braces are–again to me–the visual indicator of scope. I don't like () interspersed because it doesn't fit with that. This proposal lines up more neatly with my mental model.
Let's not get into the minutia of my aesthetic, though. This is an example of people having different preferences and reactions without the fact of that difference invalidating 'the other' view. You find the changes proposed less pleasant, I find them more pleasant.

1 Like
54

Wait, wait—that’s your argument, not mine!

You have stated that the major problem with Swift’s current syntax is that there is a big change when you switch from one closure to two closures. This is because single trailing closure syntax doesn’t require you to write out the label, nor does it require you to nest punctuation. So it’s a big change when that closure gets bumped to “non-trailing” position.

You surmise you’re willing to abandon single trailing closure syntax for double nested { argumentLabel: { ... } } notation everywhere to make it easy to add a second closure—basically, you think you’d be willing to nest punctuate everywhere and use labels everywhere just in case you want to add a second closure.

But you don’t currently choose to do so the same with the already-possible , argumentLabel: { ... }), which is “irrelevant” because...? Commas?

2 Likes
55

I like this proposal!

It's true that a similar formatting structure can be achieved today in Swift, but to me at least, that alternative formatting feels mangled and wrong. It's highly unconventional to start a function call with a single line of parameters, then switch to indented multiline formatting partway through. I've never seen it done in practice, and I don't think it will ever be adopted significantly, so I don't see it as a viable alternative to this proposal.

The difference between the two syntaxes is seemingly small, but closing the parameter list and wrapping the trailing closures in a neat set of curly braces goes a long way toward making the code feel more structured.

56

So your support of this proposal is based strongly on an aesthetic preference against })? I would think that, as a general principle, adding additional syntax shouldn’t be justified based on such grounds.

By contrast, I am not making any aesthetic argument. I am simply asserting as a self-evident condition that the human eye can find which opening brace pairs with which closing brace more easily when they are different—like this: ( { } )—than when they are the same.

This would be a major argument against this proposal, no? There are here proposed nested braces { { } } without any actual nested scopes.

7 Likes
57

I listed that as one (of five) reasons I prefer the proposed syntax, and I never came close to saying it was a "major problem"...

I'm potentially willing to do this because it increases code clarity with a syntax I prefer over keeping the expression in the argument list parens. The simplicity when adding a second closure would be a side-benefit.

I already stated my reasons for disliking the syntax, but this is exactly the argument I'm referring to. If I want to use trailing closures and I don't like the current syntax, "don't use trailing closures" is a non-starter.

58

So to be clear, you support this proposal because you find its aesthetics more pleasing than the aesthetics of the current syntax. You would argue that this preference based on aesthetic grounds is sufficient to have the syntax of the language changed/expanded to accommodate that preference. You do not base this preference on any empiric measures or comparisons of the current syntax and any proposed change, and you would not be dissuaded based on any argumentation from that perspective.

3 Likes
59

"self evident"
I'm doing what I can to avoid asserting that any of my assertions are some universally applicable or agreeable assessment. I'm probably going too far in that direction, but I prefer that to the other direction.

Sure, yes? There's more to it than that, but I don't really think that further discussion of this here in this format is actually going to successfully unpack any of it so… yes.

60

Cool. Personally, I would hope that neither mine nor anyone else’s aesthetic judgment should change the language, but if we disagree on that, then I think that’s that!

61

This sort of proposal is almost entirely aesthetic in nature. I think it's entirely appropriate to judge it based on its aesthetic merits.

1 Like