<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=""><div class="">Er, I think I misunderstood the proposal and discussion and prior work (e.g. <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md" class="">SE-0066</a>) and so my contribution to this discussion was not great. Here are my revised thoughts in light of a reread of the relevant material. Below is an outline of what I think closure signatures should look like. (For all of the below examples, the ability to explicitly include return type in the closure "preamble" is assumed.)</div><div class=""><br class=""></div><div class="">0) If a closure takes no arguments, acceptable "preambles" should be: omitting named variables and the "in" keyword, "() in", or "Void in".</div><div class=""><br class=""></div><div class="">1) If a closure takes one argument, acceptable preambles should be: "(arg) in" or "(_) in".</div><div class=""><br class=""></div><div class="">2) If a closure takes at least two arguments, acceptable preambles should be, e.g., "(x, y) in", with every spot in the tuple replaceable by an underscore.</div><div class=""><br class=""></div><div class="">3) If a closure takes at least one argument, "_ in" means that *all* arguments are ignored, regardless of how many there are. For a single-argument closure, "_ in" is shorthand for "(_) in". For multiple-argument closures, it is shorthand for "(_, _, …, _) in". "_ in" is not allowed for nullary closures.</div><div class=""><br class=""></div><div class="">4) Tuple unpacking can be achieved by replacing the variables inside the outer parentheses with tuples. For a Dictionary, whose Element is of type (key: Key, value: Value), this means writing "((key, value)) in", i.e., replacing the "arg" in "(arg) in" with "(key, value)". For a Dictionary<String, (Int, Double)>, you could do "((s, (i, d))) in". If and only if the tuple in question had named positions, they would also be allowed in the closure preamble. So for a Dictionary<String, (length: Int, score: Double)> you could write "((key: s, (length: i, score: d))) in". The rules for tuple position labels would be the same as for regular tuples (whatever those may be; I can never keep track of exactly what is (dis)allowed).</div><div class=""><br class=""></div><div class="">5) The only point I foresee sparking much debate: there should be no permissible shorthands/syntactic sugar except for those outlined above. In particular, parentheses should be required for all closures taking a nonzero number of arguments.</div><div class=""><br class=""></div><div class="">Rationale: Allowing the shorthand "arg in" suggests that when arg is a tuple, "(x, y) in" should accomplish the unpacking, which is incorrect. Allowing the shorthand "x, y in" suggests that for single-argument closures, "arg in" should be allowed, which (according to this) would be incorrect. I don't like the idea of special-casing the syntactic sugar and allowing users to drop the outer parentheses as long as the closure does not take one argument that is a tuple (I think that's the only case the compiler would be unable to resolve). Also, I would imagine the migration path to enforce parentheses around arguments is trivial to implement.</div><div class=""><br class=""></div><div class="">Requiring parentheses also finishes the job started by SE-0066. In fact it more or less perfectly mirrors <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md#proposed-solution" class="">the proposed solution</a> to the problem of function types.. The only difference here is that we're talking about argument lists, not function types, but why pass up an opportunity to unify the two?</div><div class=""><br class=""></div><div class="">—</div><div class="">Robert Bennett</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On May 27, 2017, at 8:23 AM, Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" class="">gwendal.roue@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: HelveticaNeue; font-size: 14px; 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;" class=""><blockquote type="cite" class=""><div class="">Le 27 mai 2017 à 14:20, Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" class="">gwendal.roue@gmail.com</a>> a écrit :</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 26 mai 2017 à 21:35, Robert Bennett 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=""><span 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; float: none; display: inline !important;">On the contrary I think the solution can absolutely be to break other code.<span class="Apple-converted-space"> </span></span></div></blockquote></div><br class=""><div class="">You can break whatever you want.</div><div class=""><br class=""></div><div class="">But whatever the solution you come up with, remember that SE-0110 currently *degrades* the quality of code written by Swift programmers. It can be argued that SE-0110 is a blatant *regression*. Maybe not as bad as the initial introduction of fileprivate, but something which is pretty bad, though.</div><div class=""><br class=""></div><div class="">References:</div><div class="">-<span class="Apple-converted-space"> </span><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036808.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036808.html</a></div><div class="">- <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036814.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036814.html</a></div></div></div></blockquote><br class=""></div><div style="font-family: HelveticaNeue; font-size: 14px; 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;" class="">One more link, about the loss of single-lign closures induced by SE-0110:<span class="Apple-converted-space"> </span><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036792.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036792.html</a></div><div class="" style="font-family: HelveticaNeue; font-size: 14px; 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: HelveticaNeue; font-size: 14px; 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;">Gwendal</div></div></blockquote></div><br class=""></body></html>