<div dir="ltr"><pre style="white-space:pre-wrap;color:rgb(0,0,0)">After splatting is removed, what will happen in cases where function arguments are implicitly converted to tuples, as in this code (in the repl)?</pre><pre style=""><font color="#000000"><span style="white-space:pre-wrap">  3&gt; func compose&lt;A,B,C&gt;(f:(A)-&gt;B, g:(B)-&gt;C) -&gt; (A)-&gt;C {
  4.     return { (_ arg: A) in
  5.         return g(f(arg))
  6.     }
  7. }
  8&gt;
  9&gt;
 10&gt; func f(a: Int, b: String) -&gt; String {
 11.     return &quot;Composed!&quot;
 12. }
 13&gt;
 14&gt; func g(x: String) -&gt; Int {
 15.     return x.characters.count
 16. }
 17&gt;
 18&gt; let c = compose(f, g:g)
c: (Int, b: String) -&gt; Int = 0x00007ffff7ff28d0
 19&gt;
 20&gt; c
$R0: (Int, b: String) -&gt; Int = 0x00007ffff7ff28d0
 21&gt;
 22&gt; c((9,b:&quot;Wat&quot;))
$R1: Int = 9
 23&gt;
 24&gt; c(9, b:&quot;Wat&quot;)
repl.swift:24:8: error: extra argument &#39;b&#39; in call
c(9, b:&quot;Wat&quot;)
       ^~~~~</span></font><span style="color:rgb(0,0,0);white-space:pre-wrap">
</span></pre><div>Mike</div><pre style="white-space:pre-wrap;color:rgb(0,0,0)">&gt;<i> On Jan 31, 2016, at 5:00 PM, Kevin Ballard via swift-evolution &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution">swift-evolution at swift.org</a>&gt; wrote:
</i>&gt;<i> 
</i>&gt;<i> +1 in general, though I do wonder how this change will affect generic code. For example, if I have a function that returns a tuple, and another function that takes an argument list matching the same tuple type, can I still use generic functions like map() to call the second function with the tuple from the first? I&#39;m hoping the answer is &quot;yes&quot;, because the type of a function doesn&#39;t distinguish between functions that take multiple arguments vs functions that take a single argument of tuple type and so passing functions around as first-class values should be fine. Although I imagine this change will still prevent me from writing a closure like { funcOfTwoArgs($0) } which is unfortunate, but would be solved by a subsequent proposal to add an explicit splat operator.
</i>
Yes, AFAIK, generic code isn’t affected by the proposed change.  Type checking of generic code is modular, not aware of the concrete types the generic is instantiated with.

-Chris
</pre><div><br></div></div>