<div dir="ltr"><p>+1. I had this same problem when using <code>map</code> with <code>enumerated</code>-both <code>$1</code> and <code>$0.offset</code> worked. I can see how this can be confusing to beginners.</p>
<br><br><div class="gmail_quote"><div dir="ltr">On Sat, Jun 25, 2016 at 8:36 AM Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org">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">I believe this should be done for Swift 3.0 release as this is a *source<br>
breaking change* and IMO it is very important to remove the inconsistency<br>
mentioned below.<br>
<br>
We removed tuple splatting on caller side and IMO we must complete this job<br>
to delete the implicit connection between tuple and list of parameters in<br>
closures/functions.<br>
<br>
<br>
Currently we have these "features" :<br>
====================================<br>
<br>
1. Single tuple as parameter is allowed when list of parameters are required:<br>
<br>
let ft1 : (Int,Int) -> Void = { x in print(x.0, x.1)}<br>
<br>
(but this causes crash:<br>
let ft2 : (Int,Int) -> Void = { x in print(x) }<br>
)<br>
<br>
Opinion: this should not be allowed. Parameter list is required.<br>
`(Int,Int) -> Void` and `((Int,Int)) -> Void` are two different types.<br>
<br>
<br>
2. Parameter list in closure is allowed when single tuple parameter is<br>
required:<br>
<br>
typealias IntInt = (Int,Int)<br>
typealias IntIntToVoid = (IntInt) -> Void<br>
<br>
let tuple : IntInt = (1,2)<br>
<br>
func foo(block: IntIntToVoid) { block(tuple) }<br>
<br>
foo { x, y in print(x,y)}<br>
foo { (x, y) in print(x, y)}<br>
<br>
Opinion: this should not be allowed. Tuple parameter is required.<br>
`((Int,Int)) -> Void` and `(Int,Int) -> Void` are two different types.<br>
Swift should require this syntax to assign tuple parameter's sub-values to<br>
variables in closure: `{ ((x, y)) in ..}`<br>
<br>
<br>
3. Inconsistent (and just wrong) function type when a list of parameters<br>
required(not tuple) :<br>
<br>
typealias t1 = (Int, Int) -> Int // clearly here are list of parameters<br>
typealias t2 = ((Int, Int)) -> Int // clearly here is a tuple parameter<br>
<br>
print(t1.self) // Prints ((Int, Int)) -> Int why?<br>
print(t2.self) // Prints ((Int, Int)) -> Int<br>
print(t1.self == t2.self) // true<br>
<br>
Opinion: `(Int,Int) -> Void` and `((Int,Int)) -> Void` should be two<br>
different separate types that can not be implicitly converted to each<br>
other. Swift's typesystem should separate these types.<br>
<br>
<br>
4. If the type is the same, why behavior differs :<br>
<br>
let add_list: (Int, Int) -> Int = (+)<br>
let add_tuple: ((Int, Int)) -> Int = (+)<br>
<br>
print(add_list.dynamicType == add_tuple.dynamicType) // true<br>
<br>
print( add_list(1,2) )<br>
//print( add_list((1,2)) ) // missing argument for parameter #2 in call<br>
<br>
//print( add_tuple(1,2) ) // extra argument in call<br>
print( add_tuple((1,2)) )<br>
<br>
<br>
Proposal:<br>
===============<br>
<br>
1. Separate function types with parameter list and a tuple parameter. They<br>
should be two separate types.<br>
<br>
2. Require this syntax to assign tuple parameter's sub-values to variables<br>
in func/closure: `{ ((x, y)) in ..}`, otherwise (i.e. if `{ (x, y) in ..`)<br>
treat function/closure as having list of parameters.<br>
<br>
3. Disallow implicit conversion between function/closure with a list of<br>
parameters and function/closure where single tuple is required.<br>
This will stop confusion and make the language consistent how it deal with<br>
tuples and list of parameters in func/closure.<br>
<br>
4. It seems like we should keep the ability to explicitly convert one to<br>
another as some(many?) code can depend on this current behavior and so we<br>
need a way to convert old code to new.<br>
_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">-Saagar Jha</div></div>