<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 5, 2017 at 9:31 AM, Gwendal Roué via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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></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></div><div>Gwendal</div></blockquote></div><br>+1 to this.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In practice, we have seen that the previous behaviour was incredibly versatile and it allowed for more expressive code; using tuples in generic types is much more pleasant to use (eg: Dictionary and similar collections). I suppose most users of that Dictionary API did not know that those blocks were accepting tuples and not several parameters, but still they were productive with those APIs. Now we will require them to know what I consider is a implementation detail, which adds a small cognitive load when they try to use them.</div><div class="gmail_extra"><br></div><div class="gmail_extra">So, which syntax is considered to be better? To me, every proposed syntax is worse than the previous one, even more considering that this will be a breaking change. And we do not need to invent some examples, we have real usages that we can reason about:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://github.com/Alamofire/Alamofire/blob/c8700ac7ea6b7efa7200e2920bf528e88b4dbee6/Source/ParameterEncoding.swift#L245">https://github.com/Alamofire/Alamofire/blob/c8700ac7ea6b7efa7200e2920bf528e88b4dbee6/Source/ParameterEncoding.swift#L245</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"> return components.map { "\($0)=\($1)" }.joined(separator: "&")<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I suppose that with Swift 4 that line of code will be rewritten as this:</div><div class="gmail_extra"><br></div><div class="gmail_extra"> return components.map { "\($0.0)=\($0.1)" }.joined(separator: "&")<br></div><div class="gmail_extra"><div><br></div><div>No matter the workaround, that will be the case. That is not Swift code I want to write nor maintain.</div><div><br></div><div>Can't we delay the release of SE-0110 until Swift 5, where we can reason more about its consequences? Are the gains in compilation times so impressive? Do we want to hinder such code patterns because of "type safety"? Are there any real world examples where that has been an issue?</div><div><br></div><div>Thanks,</div><div><br></div>-- </div><div class="gmail_extra">Víctor Pimentel<div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" style="font-size:12.8px"><div style="font-size:12.8px"></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div>