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

[Xiaodi Wu]

On Wed, Jun 7, 2017 at 10:12 PM, Stephen Celis <stephen.celis at gmail.com>
wrote:

> > On Jun 7, 2017, at 10:33 PM, Xiaodi Wu via swift-evolution <
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170607/c9cc0e63/attachment.html>