<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 4 juin 2017 à 19:16, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">One way to split the difference here is to eliminate the splatting behavior, but keep the destructuring (irrefutable pattern matching) behavior as well. In these cases, just require an extra explicit paren for the parameter list. This would change the diff's to:</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Example 1<br class="">- return columns.index { (column, _) in column.lowercased() == lowercaseName }<br class="">+ return columns.index { ((column, _)) in column.lowercased() == lowercaseName }<br class=""><br class="">Example 2 :<br class="">- .map { (mappedColumn, baseColumn) -> (Int, String) in<br class="">+ .map { ((mappedColumn, baseColumn)) -> (Int, String) in<br class=""><br class="">Example 3 :<br class="">- .map { (table, columns) in "\(table)(\(columns.sorted().joined(separator: ", ")))" }<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span><br class="">+ .map { ((table, columns)) in "\(table)(\(columns.sorted().joined(separator: ", ")))" }<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span><br class=""><br class="">Example 4 :<br class="">- dictionary.first { (column, value) in column.lowercased() == orderedColumn.lowercased() }<br class="">+ dictionary.first { ((column, value)) in column.lowercased() == orderedColumn.lowercased() }<br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">What do you think? Seems like it would solve the type checker problem, uglify the code a lot less, and make the fixit/migration happily trivial.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">-Chris</div></div></blockquote><br class=""></div><div>Thanks for your feedback !</div><div><br class=""></div><div>Your solution performs much better, but only to some point: the developers will just add parenthesis until the compiler is happy.</div><div><br class=""></div><div>Quoting <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md:" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md:</a></div><div><br class=""></div><div><blockquote type="cite" class="">## Motivation<br class=""><br class="">Right now, the following is possible:<br class=""><br class="">let fn1 : (Int, Int) -> Void = { x in<span class="Apple-tab-span" style="white-space: pre;"> </span><br class=""> // The type of x is the tuple (Int, Int).<br class=""> // ...<br class=""><div class="">}</div><div class=""><br class=""></div><br class="Apple-interchange-newline">let fn2 : (Int, Int) -> Void = { x, y in<div class=""> // The type of x is Int, the type of y is Int.</div> // ...<br class="">}<br class=""></blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class="">A variable of function type where there exist n parameters (where n > 1) can be assigned a value (whether it be a named function, a closure literal, or other acceptable value) which either takes in n parameters, or one tuple containing n elements. This seems to be an artifact of the tuple splat behavior removed in SE-0029.<br class=""><br class="">The current behavior violates the principle of least surprise and weakens type safety, and should be changed.<br class=""></blockquote><br class=""></div><div>The motivation section is not at all about any "type checker problem". It's about a postulate that has been proven horribly source-breaking, and counter-productive. The type safety argument is moot. The principle of least surprise has been blown away by SE-0110, putting Swift aside from the majority of other languages.</div><div><br class=""></div><div>I'm surprised that everybody tries to workaround SE-0110 consequences, admitting that it's relevant, instead of revisiting SE-0110 at its very root.</div><div><br class=""></div><div>Gwendal</div><div><br class=""></div></body></html>