<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="">Also, I want to repeat what I said on the other thread. We should revert to Swift 3 behavior for this, and then take the time to design the behavior we really want (either for 4.1 or 5). Anything else will cause us to break people’s code twice…<div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 7, 2017, at 11:50 AM, Gwendal Roué via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 7 juin 2017 à 20:33, Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" class="">gwendal.roue@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div 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;" class="">For example, take those three functions:</div><div 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;" class=""><br class=""></div><div 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;" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>func f(_ closure:(Int, Int) -> ())</div><div 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;" class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>func g(_ closure:((Int, Int)) -> ())</div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>func h(_ closure:((a: Int, b: Int)) -> ())</div><div class=""><br class=""></div><div class="">If one can always write (as in Swift 3):</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>f { (a, b) in ... }</div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>g { (a, b) in ... }</div></div><div class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>c { (a, b) in ... }</div></div></div><div class=""><br class=""></div><div class="">Then one can easily deal with a badly fit closure signature.</div><div class=""><br class=""></div><div class="">This is most examplified by dictionaries. They always expose (key: Key, value: Value) tuples (their Element type). Problem is that 'key' and 'value' are identifiers that only matter for dictionaries, not for dictionary users. It's very important for dictionary users to forget about tuples, and the `key` and `value` words:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>// No pollution</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>dictionary.map { (name, score) in ... }</div></div></div></div></blockquote><br class=""></div><div class="">It looks like some people in this mailing list are horrified by this "request" (not a feature request, but a request that Swift 3 behavior is restored, actually).</div><div class=""><br class=""></div><div class="">What could be the reasons for such a bad reaction?</div><div class=""><br class=""></div><div class="">1: measurable runtime overhead (slower programs in some cases, without any obvious way for the developper to notice where is the extra cost)</div><div class="">2: measurable compiler overhead (slower compilation)</div><div class="">3: implementation complexity (slower swift progress, technical debt, etc.)</div><div class="">4: other?</div><div class=""><br class=""></div><div class="">I understand 1. We are all fascinated by C++ and Rust "zero-overhead". If this is the main concern of the community, then we may focus the discussion of that very precise topic.</div><div class=""><br class=""></div><div class="">I can live with 2 (just a personal subjective preference)</div><div class=""><br class=""></div><div class="">About 3: I can not tell because I lack the necessary skills.</div><div class=""><br class=""></div><div class="">4: enlighten us!</div><div class=""><br class=""></div><div class="">Gwendal</div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>