<div dir="ltr"><div>I just want to say, as a "regular developer", that I'm with Vladimir S here.</div><div><br></div><div>Swift 3 (and current Swift 4) both still have a lot of inconsistencies and/or bugs related to tuple- and function types which will need to be fixed before ABI stability, and they are not fixed by going back to a state with even more inconsistencies.</div><div><br></div><div>FWIW I can't see how SE-0110 can be considered fully implemented, and this is simply because the most recent compiler still cannot properly "Distinguish between single-tuple and multiple-argument function types" (that's the title of SE-0110), this is evident in lots of different ways, here are some of them:</div><div><br></div><div><a href="https://bugs.swift.org/browse/SR-5127">https://bugs.swift.org/browse/SR-5127</a></div><div>Single-tuple and multiple-argument function types should not be considered equal</div><div><br></div><div><a href="https://bugs.swift.org/browse/SR-5128">https://bugs.swift.org/browse/SR-5128</a></div><div>Don't allow swapping a single-tuple function with a multiple-argument function</div><div><br></div><div><a href="https://bugs.swift.org/browse/SR-5129">https://bugs.swift.org/browse/SR-5129</a></div><div>Don't treat func signatures as being the same when they are in fact different</div><div><br></div><div><a href="https://bugs.swift.org/browse/SR-5130">https://bugs.swift.org/browse/SR-5130</a></div><div>Single-tuple and multiple-argument function types should be treated as different types</div><div><br></div><div>I think of the "regression"/decreased ergonomics as a price that is worth paying for, and a necessary step towards, getting the language in a state in which it is possible to get rid of Swift's current parentheses-related inconsistencies and possibly reimplement the hopefully just temporarily lost ergonomics and/or expressiveness.</div><div><br></div><div>Another related "regression" that I think is worth noting has to do with generics, namely the inability to have type parameters for function types in this form: Parameter -> Result. This is no longer possible in Swift 4 and it will instead require special casing for each number of parameters in the function types. This means that it is also impossible to make a type generic over just function types (wihtout special casing for parameter count). These things were (sort of) possible to do in earlier versions, but they couldn't make it all the way without other parts of the language falling apart. They certainly hinted about something nice, and maybe if the language is allowed to be simplified and made more consistent, they can be reimplemented in a proper way.</div><div><br></div><div>/Jens</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 8, 2017 at 3:26 PM, Vladimir.S 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08.06.2017 9:43, Jonathan Hull wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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…<br>
</blockquote>
<br></span>
Yes, *just* ignore/revert a number of connected, actively discussed and accepted, implemented(partially for some) proposals, freeze the current broken state of function types for very long period without any ability in near feature to fix it.<br>
<br>
Instead of improvement of the syntax of the problematic parts of code even after release (if not possible to suggest a suitable solution before the release). I don't think that *improvements* in syntax can break people's code.<br>
<br>
Huh..<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Jon<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jun 7, 2017, at 11:50 AM, Gwendal Roué via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>>> wrote:<div><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le 7 juin 2017 à 20:33, Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" target="_blank">gwendal.roue@gmail.com</a> <mailto:<a href="mailto:gwendal.roue@gmail.com" target="_blank">gwendal.roue@gmail.com</a><wbr>>> a écrit :<br>
<br>
For example, take those three functions:<br>
<br>
func f(_ closure:(Int, Int) -> ())<br>
func g(_ closure:((Int, Int)) -> ())<br>
func h(_ closure:((a: Int, b: Int)) -> ())<br>
<br>
If one can always write (as in Swift 3):<br>
<br>
f { (a, b) in ... }<br>
g { (a, b) in ... }<br>
c { (a, b) in ... }<br>
<br>
Then one can easily deal with a badly fit closure signature.<br>
<br>
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:<br>
<br>
// No pollution<br>
dictionary.map { (name, score) in ... }<br>
</blockquote>
<br>
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).<br>
<br>
What could be the reasons for such a bad reaction?<br>
<br>
1: measurable runtime overhead (slower programs in some cases, without any obvious way for the developper to notice where is the extra cost)<br>
2: measurable compiler overhead (slower compilation)<br>
3: implementation complexity (slower swift progress, technical debt, etc.)<br>
4: other?<br>
<br>
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.<br>
<br>
I can live with 2 (just a personal subjective preference)<br>
<br>
About 3: I can not tell because I lack the necessary skills.<br>
<br>
4: enlighten us!<br>
<br>
Gwendal<br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
</div></div><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
</blockquote>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
______________________________<wbr>_________________<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/mailma<wbr>n/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>