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

[Xiaodi Wu]

On Thu, Jun 8, 2017 at 7:53 AM, Vladimir.S <svabox at 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.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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170608/437fcc5b/attachment.html>