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 ..."
> On May 26, 2017, at 2:57 PM, Xiaodi Wu <[email protected]> wrote:
>
> Requiring parentheses in closures like that was discussed during SE-0110 and
> rejected; the rationale was that it's a useful shorthand, and that the whole
> closure syntax is wildly different from function declarations: you don't need
> to write the type of the arguments, and you don't need to write the return
> value, so why would it make sense to enforce this particular formality?
>
> At this point, I'd be very much against now requiring it. The whole rationale
> for revisiting SE-0110 is that it is breaking lots of code, and the solution
> cannot be to break lots of other code. The double parenthesis syntax or the
> let syntax for destructuring seem to be fine mitigations, the former because
> it strictly parallels the change in syntax in SE-0110 where a single tuple
> argument has two sets of parentheses, and the latter because it's the same
> destructuring syntax as is used elsewhere for pattern matching.
>> On Fri, May 26, 2017 at 11:45 David Sweeris via swift-evolution
>> <[email protected]> wrote:
>>
>> > On May 26, 2017, at 08:14, Robert Bennett via swift-evolution
>> > <[email protected]> wrote:
>> >
>> > Alternatively, for maximum consistency we could make "{ arg in ..."
>> > illegal as well, requiring parentheses around "arg". This would mirror the
>> > parentheses necessary in e.g., "let f: (Int) -> Int", and there would be
>> > no confusion as to why " { arg in ..." is legal but not "{ (key, value) in
>> > ...".
>>
>> I think I would support that. Until quite recently, I was under the
>> impression that closures' "inner signatures" were part of that proposal,
>> anyway.
>>
>> (Come to think of it... were they? I suppose it could be a bug that the
>> "old" syntax is still accepted here.)
>>
>> - Dave Sweeris
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
