> On Jun 7, 2017, at 10:33 PM, Xiaodi Wu via swift-evolution > <[email protected]> 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. 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
