> On 26 May 2017, at 20:35, Robert Bennett via swift-evolution > <[email protected]> wrote: > > On the contrary I think the solution can absolutely be to break other code. > Allowing no parentheses is not a very useful shorthand -- it only saves two > characters -- and with SE-0110 actually obscures the logic. Always requiring > parentheses makes it clear that "{ (arg) in ..." can be replaced with "{ > ((key, value)) in ..." when arg is a 2-tuple; the outer parentheses denote an > argument list, and anything inside them is the argument, consistent with > other parts of the language. Allowing "{ arg in ..." but not "{ (key, value) > in ..." is sure to leave some people scratching their heads because "{ arg in > ..." suggests that it is arguments that are passed to closures (as is the > case with functions) and not tuples. The correctness of "{ arg in ..." relies > too heavily on the equivalence between a 1-tuple and a single element, an > equivalence that does not hold for higher arities. > > I'm not *too* strongly wed to this, though. I care much more strongly about > allowing "{ ((key, value)) in ..." than prohibiting "{ arg in ...". I only > brought up the latter to try to improve the consistency of the language and > to make clear that "{ ((key, value)) in ..." is the correct way of achieving > the old style "{ (key, value) in …"
I seem to recall arguing the same with SE-0110, and still hold the same belief; requiring the parenthesis avoids a lot of ambiguity when dealing with tuples, and it's an easy migration to make (Xcode can just add parenthesis to all closures). For code that isn't migrated, syntax errors should crop up naturally anywhere the arguments and closure type no longer match. I still absolutely believe it's the right call; while closures aren't defined quite the same as functions, that's no reason not to have *some* consistency. There's possibly an argument to make for omitting the brackets on a simple, single parameter closure, but other than that I think it's better to be explicit in all cases. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
