[swift-evolution] Revisiting SE-0110

[Xiaodi Wu]

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 <
swift-evolution at swift.org> wrote:

>
> > On May 26, 2017, at 08:14, Robert Bennett via swift-evolution <
> swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170526/b46020fd/attachment.html>