[swift-evolution] Proposal: Always flatten the single element tuple

[Vladimir.S]

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/proposals/0066-standardize-function-type-syntax.md)

'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.celis at gmail.com 
> <mailto:stephen.celis at gmail.com>> wrote:
> 
>     > On Jun 7, 2017, at 10:33 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>