<div dir="ltr">Argument lists should or shouldn't be tuples. I think the question likes a concept more than a technical question.</div><div class="gmail_extra"><br><div class="gmail_quote">2017-06-07 14:56 GMT+08:00 Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span class="">On Wed, Jun 7, 2017 at 01:51 Susan Cheng <<a href="mailto:susan.doggie@gmail.com" target="_blank">susan.doggie@gmail.com</a>> wrote:<br></span><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I don't think it's a roll back change.</div></blockquote><div><br></div></span><div>Function argument lists were once tuples, but they have not been for many years. All of the proposals I listed above proceed on the basis that these are not the same. Your proposal says that function argument lists should be tuples: that is rolling back a >5 year old change, is it not?</div><div><div class="h5"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>The proposal is not proposing allow to reorder the parameters by using the tuple or implicit tuple splat to fit the function parameters.</div><div>It's just clarify the relationship of tuples and argument lists.</div><div><br></div><div>as the grammar of Swift 3, it's allowed wrapping the argument with a single tuple to a function with two argument.</div><div><br></div><div><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)">[(<span style="color:rgb(39,42,216)">1</span>, <span style="color:rgb(39,42,216)">2</span>)].map(+)</p></div><div><br></div><div>and SE-0110 is the proposal make the distinguished and not allowed this line of code.</div><div><br></div><div>although we fix the compiler to accept the destructuring of tuples</div><div><br></div><div><p style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)">[(<span style="color:rgb(39,42,216)">1</span>, <span style="color:rgb(39,42,216)">2</span>)].map({ ((lhs, rhs)) <span style="color:rgb(186,45,162)">in</span> lhs + rhs })</p></div><div><br></div><div>it's not accepting the code of <span style="color:rgb(0,0,0);font-family:Menlo;font-size:11px">[(</span><span style="font-family:Menlo;font-size:11px;color:rgb(39,42,216)">1</span><span style="color:rgb(0,0,0);font-family:Menlo;font-size:11px">, </span><span style="font-family:Menlo;font-size:11px;color:rgb(39,42,216)">2</span><span style="color:rgb(0,0,0);font-family:Menlo;font-size:11px">)</span><span style="color:rgb(0,0,0);font-family:Menlo;font-size:11px">].map(+)</span> which the operator + are not function with accepting the tuple of two elements.</div><div><br></div><div>the only way we can thought is that the arguments with single tuple is flattened and it's most compatible with Swift 3.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-06-07 13:05 GMT+08:00 Xiaodi Wu <span><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is not what was meant during discussion about re-evaluating SE-0110. Tuples already behave as described, but function argument lists are not tuples and have not been for a very long time: see SE-0029, SE-0066.<br><br>Also, consider SE-0046, which makes possible labels in single-argument argument lists (not possible in tuples), and SE-0060, which prohibits arbitrary reordering (although still possible in tuples). This is to say that the whole direction of Swift since version 2 has been to erase the historical relationship between tuples and argument lists.<br><br>The question is how to accommodate some common use cases for destructuring as a matter of syntactic sugar after having carefully distinguished argument lists and tuples in the compiler, which is a given, not how to roll back a change that was settled in 2011, by Chris’s telling.<div class="m_-7553769221275334239m_-8646623255503982822HOEnZb"><div class="m_-7553769221275334239m_-8646623255503982822h5"><br><div class="gmail_quote"><div>On Tue, Jun 6, 2017 at 23:14 Susan Cheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br style="font-size:14px"><span style="font-size:14px">func add2(_ pair: (Int, Int)) -> Int {</span><br style="font-size:14px"><span style="font-size:14px"> return pair.0 + pair.1</span><br style="font-size:14px"><span style="font-size:14px">}</span><br><div><span style="font-size:14px"><br></span></div></div><div><div><span style="font-size:14px">consider the follows</span></div><div><br></div><span style="font-size:14px">let _add2 = </span><span style="font-size:14px">add2 // </span><span style="font-size:14px">add2 have the typeof `((Int, Int)) -> Int`, it should flatten to </span><span style="font-size:14px">`(Int, Int) -> Int`</span><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">so these two lines are also acceptable</span></div></div><div><div><span style="font-size:14px">[(1, 2)].map(add1)</span><br style="font-size:14px"><span style="font-size:14px">[(1, 2)].map(add2)</span><span style="font-size:14px"><br></span></div><div><span style="font-size:14px"><br></span></div></div><div><div><span style="font-size:14px">this proposal is not just changing the behaviour of closure, this proposal also changing the tuple type</span></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">(((Int, Int))) flatten to (Int, Int)</span></div><div><span style="font-size:14px">(Int, </span><span style="font-size:14px">(((Int, Int))), Int</span><span style="font-size:14px">)</span><span style="font-size:14px"> flatten to </span><span style="font-size:14px">(Int, </span><span style="font-size:14px">(Int, Int)</span><span style="font-size:14px">, Int)</span></div><div><span style="font-size:14px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-06-07 12:03 GMT+08:00 Stephen Celis <span><<a href="mailto:stephen.celis@gmail.com" target="_blank">stephen.celis@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The inline cases make sense to me, but my concern for ambiguity are because we can define both of these functions:<br>
<br>
func add1(_ x: Int, _ y: Int) -> Int {<br>
return x + y<br>
}<br>
func add2(_ pair: (Int, Int)) -> Int {<br>
return pair.0 + pair.1<br>
}<br>
<br>
// What's the behavior here?<br>
[(1, 2)].map(add1)<br>
[(1, 2)].map(add2)<br>
<br>
What comes to mind, though, is, Swift already prevents single-element tuples, so why not prevent functions that take a single tuple as the only argument?<br>
<br>
Swift could provide a fix-it for functions that take single tuples and say: "Swift functions cannot take a single tuple. Please write a function that takes as many arguments as the tuple specified."<br>
<br>
Considering the fact that Swift generally operates in a multi-argument world, and given that functions taking a single tuple are the minority, I think this would be a good way to move forward.<br>
<span class="m_-7553769221275334239m_-8646623255503982822m_-4582185173595280366m_7787822943553668362HOEnZb"><font color="#888888"><br>
Stephen<br>
</font></span><div class="m_-7553769221275334239m_-8646623255503982822m_-4582185173595280366m_7787822943553668362HOEnZb"><div class="m_-7553769221275334239m_-8646623255503982822m_-4582185173595280366m_7787822943553668362h5"><br>
> On Jun 6, 2017, at 11:21 PM, Susan Cheng <<a href="mailto:susan.doggie@gmail.com" target="_blank">susan.doggie@gmail.com</a>> wrote:<br>
><br>
> [(1, 2)].map({ x, y in x + y }) // this line is correct<br>
> [(1, 2)].map({ tuple in tuple.0 + tuple.1 }) // this line should not accepted<br>
><br>
> or<br>
><br>
> [(1, 2)].map({ $0 + $1 }) // this line is correct<br>
> [(1, 2)].map({ $0.0 + $0.1 }) // this line should not accepted<br>
><br>
> it's because `((Int, Int)) -> Int` always flatten to `(Int, Int) -> Int`<br>
> so, it should only accept the function with two arguments<br>
><br>
><br>
><br>
> 2017-06-07 11:07 GMT+08:00 Stephen Celis <<a href="mailto:stephen.celis@gmail.com" target="_blank">stephen.celis@gmail.com</a>>:<br>
> I like this a lot, but how do we solve for the function case?<br>
><br>
> func add(_ x: Int, _ y: Int) -> Int {<br>
> return x + y<br>
> }<br>
> [(1, 2)].map(add)<br>
><br>
> Where does `map` with a function of `((Int, Int)) -> Int` fit in?<br>
><br>
> > On Jun 6, 2017, at 10:15 PM, Susan Cheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
> ><br>
> > Introduction<br>
> ><br>
> ><br>
> > Because the painful of SE-0110, here is a proposal to clarify the tuple syntax.<br>
> ><br>
> > Proposed solution<br>
> ><br>
> > 1. single element tuple always be flattened<br>
> ><br>
> > let tuple1: (((Int))) = 0 // TypeOf(tuple1) == Int<br>
> ><br>
> > let tuple2: ((((Int))), Int) = (0, 0) // TypeOf(tuple2) == (Int, Int)<br>
> ><br>
> > 2. function arguments list also consider as a tuple, which means the function that accept a single tuple should always be flattened.<br>
> ><br>
> > let fn1: (Int, Int) -> Void = { _, _ in }<br>
> ><br>
> > let fn2: ((Int, Int)) -> Void = { _, _ in } // always flattened<br>
> ><br>
> > let fn3: (Int, Int) -> Void = { _ in } // not allowed, here are two arguments<br>
> ><br>
> > let fn4: ((Int, Int)) -> Void = { _ in } // not allowed, here are two arguments<br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > swift-evolution mailing list<br>
> > <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</blockquote></div>
</div></div></blockquote></div><br></div>
</blockquote></div></div></div></div>
</blockquote></div><br></div>