On Thu, Jun 8, 2017 at 7:53 AM, Vladimir.S <sva...@gmail.com> wrote: > 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*? > (https://github.com/apple/swift-evolution/blob/master/propos > als/0066-standardize-function-type-syntax.md) >
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. 'Proposed solution' section of this proposal clearly separates function > *type* of one tuple argument and of a list of arguments, no? > > 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. > > This is why I can't understand, how revisiting of SE-0110 *can help at > all* ? > > 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. > > 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. > > Vladimir. > > On 08.06.2017 6:34, Xiaodi Wu via swift-evolution wrote: > >> On Wed, Jun 7, 2017 at 10:12 PM, Stephen Celis <stephen.ce...@gmail.com >> <mailto:stephen.ce...@gmail.com>> wrote: >> >> >> > On Jun 7, 2017, at 10:33 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> > >> > 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? >> >> 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. >> >> 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. >> >> >> 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`: >> >> >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. >> >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. >> >The current implementation has a ton of implementation bugs - it >> doesn't work reliably. >> >The current implementation adds complexity to the type checker, slowing >> it down and adding maintenance burden. >> >The current implementation doesn't work the way we would want a tuple >> splat operation to work. >> >> ... >> >> >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. >> >> However, >> >> >[A]ctually designing this feature would be a non-trivial effort... >> >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. >> >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). >> >> 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. >> >> 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. >> >> 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. >> >> Stephen >> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution