On 29.05.2017 21:07, Robert Bennett wrote:
The word you're looking for is inconvenient 😁
If we allow dropping parentheses for tuples then we should disallow the outer
parentheses to avoid ambiguity between multi-argument closures and closures
taking
a single tuple as their argument. Then, a closure taking multiple arguments
would
have to be written as "x, y in" and a closure taking a tuple as "(x, y) in". I'm
ok with this too. I just want to make sure whatever solution we come up with
adheres to the goal of SE-0110, which is to clearly separate functions taking
multiple arguments from functions taking a tuple. For clarity, whatever solution
we come up with should wrap the arguments within a tuple in an extra pair of
parentheses. So for a multi-argument and single-tuple closure, respectively,
either "x, y in" and "(x, y) in", or "(x, y) in" and "((x, y)) in".
Well, from my point of view closure deserves some special syntax and rules. And
IMO
it is important to support currently allowed syntax of {x,y in} == {(x,y) in ..} to
reduce the code breaking changes and to keep simple clear syntax in most situations.
But we should resolve the ambiguity related to tuple splatting/deconstructing in
arguments of closure. Two ways: disallow this feature or introduce separate syntax.
So, the only *correct* way I see - is use of ((x,y)) for deconstructing tuple
argument.
In this case, when close with single tuple argument(say of type (Int,Int)) is
required, we can write this:
{tuple in ...}
{(tuple) in ...}
{((x,y)) in ...} // tuple deconstruction into x and y variables
//{(x,y) in ...} // should be disallowed
the ((x,y)) syntax follows the way of SE-0066's type of function with single tuple
argument:"...
(Int, Int) -> Int // function from Int and Int to Int
((Int, Int)) -> Int // function from tuple (Int, Int) to Int
..."
Again, please note that SE-0110 is based on previous accepted proposals: SE-0066 and
SE-0029.
On May 29, 2017, at 1:32 PM, Vladimir.S via swift-evolution
<[email protected]> wrote:
On 29.05.2017 18:26, Nevin Brackett-Rozinsky via swift-evolution wrote: On
Sun, May 28, 2017 at 7:04 PM, John McCall via swift-evolution
<[email protected] <mailto:[email protected]>> wrote: 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. I agree with John, the best thing for actually
using Swift is to allow tuple destructuring here, and the outermost
parentheses (around the entire parameter list of a closure) should continue to
be optional. Requiring double-parens would seem unnecessarily and
arbitrarily…whatever the opposite of “convenient” is. Nevin
If I understand correctly, correct me if I'm wrong, after *full* implementation
of SE-0066, the function with two parameters should have different type than
function with one tuple parameter:
I.e. typealias FuncParams = (Int, Int)->() typealias FuncTuple = ((Int,
Int))->()
print(FuncParams.self) // should be (Int, Int)->() print(FuncTuple.self) //
should be ((Int, Int))->()
So, if we have
func barParams(_ f: FuncParams) { f(1,2) }
func barTuple(_ f: FuncTuple) { f((1,2)) }
and
func fooWithParams(_ x: Int, _ y: Int) { } func fooWithTuple(_ tuple: (Int,
Int)) { }
.. we should not be able to call
barParams(fooWithTuple) // should be error: incompatible types
barTuple(fooWithParams) // should be error: incompatible types
If so, are you suggesting that this code should still be valid?
barParams({tuple in}) // ? barTuple({x,y in}) // ?
Will {x,y in} closure has ((Int, Int))->() type in this case? And if {tuple in}
should be of type (Int,Int)->() ?
If I'm not missing something, the only reasonable solution here is follow the
SE-0066 rules for function types and allow special syntax ((x,y)) to deconstruct
tuple parts in closure argument list, and such closure will have type
((Int,Int))->() as expected. So we'll have:
barTuple({((x,y)) in ... })
_______________________________________________ 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
