<div dir="ltr">On Wed, Jun 7, 2017 at 10:12 PM, Stephen Celis <span dir="ltr"><<a href="mailto:stephen.celis@gmail.com" target="_blank">stephen.celis@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">> On Jun 7, 2017, at 10:33 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> However, what I don’t get is why you’d have a mismatch here. Your method `first` accepts a closure, and surely the type it expects should be `((String, Conversation)) -> Bool` instead, since that is the type that the `filter` method expects in the body of your implementation?<br>
<br>
</span>I must continue to ask for more justification as to why it's _so_ valuable to consider "(Int,Int)->()" and "((Int,Int))->()" to be different in _most_ cases. Even in the contrived-described example above, the function may be reusable and the engineer may pass "String" and "Conversation" objects directly in some cases, and this distinction only makes things more difficult and requires cumbersome workarounds.<br>
<br>
I know you feel that the ship has sailed, and I understand the ambiguities these proposals intended to clarify, but for the most common cases, treating a function that takes a single tuple the same way we treat a function that takes the same number of values that same tuple contains is...really nice, so maybe there's a better way to disambiguate.<br></blockquote><div><br></div><div>Again, an argument list was once a tuple: this solution was investigated and "completely abandoned" early in the development of Swift "for a large number of reasons (including inout, default arguments, variadic arguments, labels, etc)". Removal of implicit tuple splatting was outlined in SE-0029. Namely, for a function `foo(_:b:)` called using a tuple `x`:</div><div><br></div><div>>A call to foo(x) looks like a call to an overloaded version of foo, both to the compiler and to the human who maintains the code. This is extremely confusing if you don't know the feature exists.</div><div>>There are real ambiguities in the syntax, e.g. involving Any arguments and situations where you want to pass a tuple value as a single parameter.</div><div>>The current implementation has a ton of implementation bugs - it doesn't work reliably.</div><div>>The current implementation adds complexity to the type checker, slowing it down and adding maintenance burden.</div><div>>The current implementation doesn't work the way we would want a tuple splat operation to work.</div><div><br></div><div>...</div><div><br></div><div>>The root problem here is that we use exactly the same syntax for both forms of function application. If the two forms were differentiated (an option considered in “alternatives considered” below) then some of these problems would be defined away.</div><div><br></div><div>However,</div><div><br></div><div>>[A]ctually designing this feature would be a non-trivial effort...</div><div><div>>We don't have an obvious sigil to use. "prefix-star" should be left unused for now in case we want to use it to refer to memory-related operations in the future.</div><div>>Making the tuple splat operation great requires more than just fixing the syntactic ambiguities we have, it would require re-evaluating the semantics of the operation (e.g. in light of parameter labels, varargs and other features).</div></div><div><br></div><div>The removal of tuple splatting was approved during Swift *2* Evolution; it so happens that one particular segment of the feature was not excised until SE-0110, but the writing was on the wall, so to speak, for 18 months.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
I'll work with whatever final solution the Swift team comes up with, but in the meantime I'm not going to shy away from reacting to regressions.<br>
<br>
I've referred to these regressions as "ergonomic" in the past, but it's more about expressiveness. Swift 3 (and earlier) syntax allowed for functional, point-free expression that could amount to very succinct, readable code. The code Swift 4 requires is harder to read and harder to maintain.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
Stephen<br>
<br>
</font></span></blockquote></div><br></div></div>