On 01.06.2017 0:42, John McCall wrote:
On May 31, 2017, at 2:02 PM, Stephen Celis <[email protected]> wrote:
On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
<[email protected]> wrote:
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.
Closure parameter lists are unfortunately only half of the equation here. This
change also regresses the usability of point-free expression.
The consequences for point-free style were expected and cannot really be
eliminated without substantially weakening SE-0110. Closure convenience seems
to
me to be a much more serious regression.
John, do you also want to say "and without weakening SE-0066"? Because, if I
understand correctly, in this case:
func add(_ x: Int, _ y: Int) -> Int {
return x + y
}
zip([1, 2, 3], [4, 5, 6]).map(add)
.. we have a clear function type mismatch situation, when map() expects function of
type ((Int, Int))->Int, but function of type (Int,Int)->Int is provided ? So probably
the additional 'reason' of the 'problem' in this case is SE-0066, no?
Or I don't understand the SE-0066 correctly..
Do we want to allow implicit conversions between function type ((Int,Int))->Int and
(Int,Int)->Int?
Quote from SE-0066:
---
(Int, Int) -> Int // function from Int and Int to Int
((Int, Int)) -> Int // function from tuple (Int, Int) to Int
---
During this discussion I see a wish of some group of developers to just return back
tuple splatting for function/closure arguments, so they can freely send tuple to
function/closure accepting a list of parameters(and probably vise-versa).
Is it worth to follow SE-0066 and SE-0110 as is, i.e. disallow tuple deconstructing
and then, as additive change improve the situation with tuple
splatting/deconstructing later with separate big proposal?
Btw, about the SE-0110 proposal. It was discussed, formally reviewed and accepted. I
expect that its revision also should be formally proposed/reviewed/accepted to
collect a wide range of opinions and thoughts, and attract the attention of
developers in this list to the subject.
Also, if we revisit SE-0110, will this code be allowed?:
func foo(_ callback: ((Int,Int))->Void) {}
let mycallback = {(x:Int, y:Int)->Void in }
foo(mycallback)
and
func foo(_ callback: (Int,Int)->Void) {}
let mycallback = {(x: (Int, Int))->Void in }
foo(mycallback)
If so, what will be result of this for both cases? :
print(type(of:mycallback)) // (Int,Int)->Void or ((Int,Int))->Void
If allowed, do we want to allow implicit conversion between types (Int,Int)->Void and
((Int,Int))->Void in both directions? (Hello tuple splatting?)
John.
func add(_ x: Int, _ y: Int) -> Int { return x + y }
zip([1, 2, 3], [4, 5, 6]).map(add)
// error: nested tuple parameter '(Int, Int)' of function '(((_.Element,
_.Element)) throws -> _) throws -> [_]' does not support destructuring
This may not be a common pattern in most projects, but we heavily use this style
in the Kickstarter app in our functional and FRP code. Definitely not the most
common coding pattern, but a very expressive one that we rely on.
Our interim solution is a bunch of overloaded helpers, e.g.:
func tupleUp<A, B, C>(_ f: (A, B) -> C) -> ((A, B)) -> C { return }
zip([1, 2, 3], [4, 5, 6]).map(tupleUp(add))
Stephen
.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
