> On May 27, 2017, at 8:01 AM, Vladimir.S via swift-evolution
> <[email protected]> wrote:
>
> Regarding the requiring of parentheses for arguments in closures: I'd suggest
> to look into SE-0066's paragraph "Should we require parentheses in closure
> expression parameter lists?" and "Rationale" for this SE:
> https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000138.html
> (SE-0066:
> https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md)
>
> Personally I agree that closures worth their own syntax and that it is
> important to keep closure's syntax lightweight. So, IMO we should keep {x, y
> in ..} syntax for closures and this should be jut equivalent for {(x, y) in
> ..}, i.e. one can use first or second depending on his/her style.
>
> I think the idea of double parentheses for tuple argument destructing in
> closure is the best solution as it has a relationship to introduced by
> SE-0066 type of function with tuple argument. I.e. :
Yes, I agree. We need to add back tuple destructuring in closure parameter
lists because this is a serious usability regression. If we're reluctant to
just "do the right thing" to handle the ambiguity of (a,b), we should at least
allow it via unambiguous syntax like ((a,b)). I do think that we should just
"do the right thing", however, with my biggest concern being whether there's
any reasonable way to achieve that in 4.0.
John.
>
> func foo(_ x: (Int, Int)) {..}
>
> type(of: foo) // should be ((Int, Int)) -> ()
> // note: not (Int, Int) -> ()
>
> var g : ((Int, Int))->() = f
>
> g = {((x1, x2)) in ... } // feels like correct syntax for type ((Int,
> Int))->()
> g = {pair in ... } // also OK, single tuple argument
>
> g = {(x1, x2) in ...} // should be ERROR: incompatible type of closure
>
> But during the discussion of SE-0110 there was some negative reaction for
> this idea.
>
> Btw, while we are discussing SE-0110 and SE-0066, I'd like to point to
> another change that can IMO have impact for functional programming, so I
> believe it is better to discuss this also.
> Currently(Swift 3.1) we are allowed to have this:
>
> var f : ()->() = {x in print(x)}
> f() // ()
> f = {_ in print(x)}
>
> I.e. you can now assign a closure with single argument as function type that
> has 0 parameters(because of implicit Void argument).
>
> Also, after SE-0066 and 0110 implemented, passing Void to function declared
> without parameters should not be allowed, so for example you can't call
> f(print("sdfsdf")) i.e. can't pass result of Void to some other function that
> is declared without parameters.
>
> Small naive example:
>
> func schedule<T>(with: T, do: (T) -> Void) {...}
>
> //--- can't change this function for some reason ---
> func foo() { .. } // just do something
> //---
>
> current code:
>
> schedule(with: (), do: foo)
>
> new code:
>
> schedule(with: (), do: {_ in foo()})
>
> Actually I believe this is a good change, but should be taken into
> consideration.
>
> Vladimir.
>
> On 26.05.2017 22:35, Robert Bennett via swift-evolution 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 ..."
>> On May 26, 2017, at 2:57 PM, Xiaodi Wu <[email protected]
>> <mailto:[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] <mailto:[email protected]>> wrote:
>>>
>>>
>>> > On May 26, 2017, at 08:14, Robert Bennett via swift-evolution
>>> <[email protected] <mailto:[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] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> _______________________________________________
>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
