<div dir="ltr">On Thu, Jun 8, 2017 at 7:53 AM, Vladimir.S <span dir="ltr"><<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Xiaodi, I'm interested in your opinion, don't you think that *SE-0066* was the main proposal that separated (Int,Int)->() and ((Int,Int))->() function *types*?<br>
(<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md" rel="noreferrer" target="_blank">https://github.com/apple/swif<wbr>t-evolution/blob/master/propos<wbr>als/0066-standardize-function-<wbr>type-syntax.md</a>)<br></blockquote><div><br></div><div>As far as I can tell, SE-0110 clarified the spelling for a single tuple argument, SE-0066 standardized the syntax for an argument list, and SE-0029 clarified the behavior of function applications. However, the notion that (Int, Int) -> () and ((Int, Int)) -> () should be different types, independent of whether we knew how the two would be spelled, is the inevitable consequence of distinguishing argument lists from tuples. According to SE-0029, that change apparently occurred *before Swift 1*, and so unless I'm mistaken the remainder of this issue has really been technical debt since that time.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
'Proposed solution' section of this proposal clearly separates function *type* of one tuple argument and of a list of arguments, no?<br>
<br>
It seems like this proposal was NOT fully implemented in Swift 3 or was implemented with bugs, or full implementation was delayed, and it just should be fully implemented in Swift 4, independent of SE-0110 proposal.<br>
<br>
This is why I can't understand, how revisiting of SE-0110 *can help at all* ?<br>
<br>
OK, let's say we revisited/rejected SE-0110, let's forgot about it for a moment. What's next? How the problem with two *separated* types for func/closure should be solved when one type is expected and other type is provided? Definitely we need new formal proposal for this to discuss in details.<br>
<br>
Again, even *without* SE-0110 type of (Int,Int)->() should be in Swift 4 not the same as ((Int,Int))->(). This means that you can't "just sent" instance of one type if other type is required.<br>
<br>
Vladimir.<br>
<br>
On 08.06.2017 6:34, Xiaodi Wu via swift-evolution wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Jun 7, 2017 at 10:12 PM, Stephen Celis <<a href="mailto:stephen.celis@gmail.com" target="_blank">stephen.celis@gmail.com</a> <mailto:<a href="mailto:stephen.celis@gmail.com" target="_blank">stephen.celis@gmail.co<wbr>m</a>>> wrote:<div><div class="h5"><br>
<br>
> On Jun 7, 2017, at 10:33 PM, Xiaodi Wu 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:<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>
I must continue to ask for more justification as to why it's _so_ valuable to<br>
consider "(Int,Int)->()" and "((Int,Int))->()" to be different in _most_ cases.<br>
Even in the contrived-described example above, the function may be reusable and<br>
the engineer may pass "String" and "Conversation" objects directly in some cases,<br>
and this distinction only makes things more difficult and requires cumbersome<br>
workarounds.<br>
<br>
I know you feel that the ship has sailed, and I understand the ambiguities these<br>
proposals intended to clarify, but for the most common cases, treating a function<br>
that takes a single tuple the same way we treat a function that takes the same<br>
number of values that same tuple contains is...really nice, so maybe there's a<br>
better way to disambiguate.<br>
<br>
<br>
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`:<br>
<br>
>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.<br>
>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.<br>
>The current implementation has a ton of implementation bugs - it doesn't work reliably.<br>
>The current implementation adds complexity to the type checker, slowing it down and adding maintenance burden.<br>
>The current implementation doesn't work the way we would want a tuple splat operation to work.<br>
<br>
...<br>
<br>
>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.<br>
<br>
However,<br>
<br>
>[A]ctually designing this feature would be a non-trivial effort...<br>
>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.<br>
>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).<br>
<br>
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.<br>
<br>
I'll work with whatever final solution the Swift team comes up with, but in the<br>
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<br>
about expressiveness. Swift 3 (and earlier) syntax allowed for functional,<br>
point-free expression that could amount to very succinct, readable code. The code<br>
Swift 4 requires is harder to read and harder to maintain.<br>
<br>
Stephen<br>
<br>
<br>
<br>
<br></div></div><span class="">
______________________________<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>
<br>
</span></blockquote>
</blockquote></div><br></div></div>