Add Tuple unsplatting - Removed by SE-0110

Tutple-unsplatting-SE-0110.md

Add Tuple unsplatting

As a side effect of SE-0110 tuple unsplating was removed from the language.

While this claims to make tooling like the type checker faster, it deals quite a blow to expressivity.

Filterting dictionaries is just an example and maybe not the best. However I hope the point gets across. Let's compare to other languages.

Examples of pattern matching in closure parameters:

Swift

let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter { arg in
  let (_, age) = arg // Awkward :| No tuple unsplatting
  return age >= 18
}

// OR

// Still No tuple unsplatting
let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter { $0.1 >= 18 } 

// OR

// Somewhat better
let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter {(arg: (name: String, age: Int)) in arg.age >= 18 }

Kotlin

mapOf("Tom" to 33, "Rebecca" to 17, "Siri" to 5).filter({ (_, age) -> age >= 18 })

Python 2.7

{name: age for name, age in {'Tom': 33, 'Rebecca': 17, 'Siri': 5}.iteritems() if age >= 18 }

Ruby

{"Tom" => 33, "Rebecca" => 17, "Siri" => 5}.select{ |_, age| value >= 18 }

Haskell

filter (\(_,age) -> age>= 18) [("Tom", 33), ("Rebecca", 17), ("Siri", 5)]

Clojure

(filter (fn [[_ age]] (>= age 18)) {"Tom" 33 "Rebecca" 17 "Siri" 5})

Scala

List(("Tom" , 33), ("Rebecca", 17), ("Siri", 5)).filter{ case (_, age) => age >= 18}

Rust

[("Tom", 33), ("Rebecca", 17), ("Siri", 5)].into_iter().filter(|&&(_, age)| age >= 18);

JavaScript

Object.entries({Tom: 33, Rebecca: 17, Siri: 5}).filter(([_, age]) => value >= 18)

Erlang

[T || {_, Age} = T <- [{"Tom", 33}, {"Rebecca", 17}, {"Siri", 5}], Age > 18].

CLisp

(remove-if-not #'(lambda (x) (>= (cadr x) 18)) '(("Tom" 30) ("Rebecca" 17) ("Siri" 5)))

And as stated on Slack, I much prefer consistency over magic. So instead of going backwards and revoke SE-110, I'd much prefer going forward and make a new proposal to have a way for deconstructing tuples directly. For example I'd love to see a SE proposal to allow this kind of syntax, rather than reverting SE-110 (and bringing back ambiguous function calls if we revert it):

arrayOfTuples.filter { _: (a,b) in print(a, " - ", b) }

Which in fact is almost possible today, using:

arrayOfTuples.filter { tuple: (a,b) in print(tuple.a, " - ", tuple.b) }

So such a proposal would simple ad the ability to use anonymous arguments for deconstructing tuples.

This way, with that feature (and in addition of the extension on Dictionary I suggested above) we'd have (1) improved type checker performance (because we removed the ambiguity thanks to SE-110), (2) still nice syntax and call sites (thanks to proper variants of filter/forEach/map/flatMap/… functions on Dictionary) and (3) still a way to deconstruct a tuple (but explicitly to keep consistency and avoid type-checker nightmare) easily if needs be (which again I don't believe will be used that much once we improved Dictionary's filter/forEach/map/flatMap signatures, but at least if we do need that deconstruction for the 1% of remaining cases, we can)

@AliSoftware good suggestion. I will change the wording of the title and the content to reflect your point.

i don't think making tooling easier at the expense of the people who use tools is the right tradeoff. Especially when this is not the case in other languages.

@blender: Again:

1. Where you think other languages offer that magic-unsplatting possibility, I don't think it's the case for all and I think you misinterpret the availability of dedicated function overloads on Hash/Dictionary for these languages as magic unsplatting while it's just a proper definition of those methods on Hash which takes 2 arguments (and not one single tuple arg)
2. The tooling and the state before SE-110 was already at the expense of the users of the tooling — because it was one of the reasons why the type checker was slow. If you imagine that we have SE-110 which allows a speed increase on the type checker, but also add the extensions on Dictionary to take closure with 2 params (instead of a single 2-items tuple param), and the suggestion I added to deconstruct a tuple explicitly in my last comment, with all those 3 features we could have all the features that you need, + consistency + a Swift compiler and type checker that works faster. Sure that would give you less excuses to go take your coffee or switch to youtube to watch some cats videos while you're compiling, but I think that consistency, speed and still having the expressiveness with the solutions I suggest is a best way forward than trying to revert things and go backwards into a world of inconsistency and magic

@AliSoftware I think I will have other occasions for coffee and cat videos so I'm all up for speed while keeping expressivity :)

Define this:

prefix operator *

prefix func *<A1,A2,R>(f: @escaping  (A1, A2) -> R) -> ((A1, A2)) -> R {
  return { (tuple: (A1, A2)) -> R in
    f(tuple.0, tuple.1)
  }
}

prefix func *<A1,A2,A3,R>(f: @escaping  (A1, A2, A3) -> R) -> ((A1, A2, A3)) -> R {
  return { (tuple: (A1, A2, A3)) -> R in
    f(tuple.0, tuple.1, tuple.2)
  }
}

// We could add some for tuples with 4 items, but I don't think people have a lot of real-world cases with tuples with more than 4 items (at that point, create a struct already)

Then even after SE-110 you can:

func foo(_ x: Int, _ y: Int) -> Int {
  return x + y
}

[(1,2),(3,4),(5,6)].map(*foo) // valid even after SE-110

let o1 = Observable<Int>.from(1,2,3)
let o2 = Observable<Int>.from(4,5,6)
Observables.zip(o1, o2, combine: *foo)

Note that, even before SE-110, in Swift 3 you were already not able to do this anymore:

let tuple = (1,2)
foo(tuple)
// error: passing 2 arguments to a callee as a single tuple value has been removed in Swift 3
// foo(tuple)
// ^  ~~~~~~~

So I'm not sure why people are so upset with SE-110 being applied to closures while the exact same rule was already applied to functions but nobody rioted back then ^^