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

[Xiaodi Wu]

On Wed, Jun 7, 2017 at 14:33 Gwendal Roué via swift-evolution <
swift-evolution at swift.org> wrote:

> Le 7 juin 2017 à 17:15, Vladimir.S <svabox at gmail.com> a écrit :
>
> On 07.06.2017 16:20, Gwendal Roué wrote:
>
> Le 7 juin 2017 à 15:11, Xiaodi Wu <xiaodi.wu at gmail.com <
> mailto:xiaodi.wu at gmail.com <xiaodi.wu at gmail.com>>> a écrit :
>
> While SE-0025 was generally regarded as unfortunate, the thousands of
> emails that followed relitigating it were much, much worse.
>
> The removal of implicit tuple splatting, which is *not* SE-0110, was
> approved on the understanding that it would be a regression until explicit
> tuple splatting is introduced. This tradeoff was considered and approved.
> It’s clear that you disagree, but that is not grounds to divert a necessary
> discussion on mitigating SE-0110 into relitigating something else.
>
> Push me out if you want, but will you push out those blatant wounds out as
> well?
> Example 1
> -        return columns.index { (column, _) in column.lowercased() ==
> lowercaseName }
> +        return columns.index { $0.0.lowercased() == lowercaseName }
>
>
> Why not
> columns.index { (arg: (column: String, _: Int)) in arg.column.lowercased()
> == lowercaseName }
> ?
>
>
> It would works, but it's less than ideal: the `args` name has no meaning.
> We have an extra type declaration instead of type inference. It's much
> longer. The clarity is tremendously reduced.
>
> - return columns.index { (column, _) in column.lowercased() ==
> lowercaseName }
> + return columns.index { (arg: (column: String, _)) in
> arg.column.lowercased() == lowercaseName }
>
> Yes, I understand that first syntax short and not verbose, but the
> alternative you provided IMHO much worse than explicit type declaration in
> closure.
>
>
> It's not an "alternative": it's Swift 3.
>
> Maybe you did already profit from it, but did not notice.
>
>
> Example 2 :
> -            .map { (mappedColumn, baseColumn) -> (Int, String) in
> +            .map { (pair) -> (Int, String) in
> +                let mappedColumn = pair.key
> +                let baseColumn = pair.value
>
>
> Can't compile something like this even in Swift 3, could you provide a
> small code snippet for this?
>
>
> Sure:
>
>     let mapping: [String: String] = ...
>     mapping.map { (mappedColumn, baseColumn) -> (Int, String) in ... }
>
> Example 3 :
> -                .map { (table, columns) in
> "\(table)(\(columns.sorted().joined(separator: ", ")))" }
> +                .map { "\($0.key)(\($0.value.sorted().joined(separator:
> ", ")))" }
>
>
> Same, why not
>
> .map { (arg: (table: String, columns: [String])) in
> "\(arg.table)(\(arg.columns.sorted().joined(separator: ", ")))" }
>
>
> Same answer: the extra `args` works, but we still have an ergonomics
> regression from Swift 3.
>
> Example 4 :
> -                dictionary.first { (column, value) in column.lowercased()
> == orderedColumn.lowercased() }
> +                dictionary.first { $0.key.lowercased() ==
> orderedColumn.lowercased() }
>
>
> Same.
>
>
> Indeed.
>
>
> See also messages from Stephen Cellis, who shows how other kinds of
> developer code has lost expressivity and clarity with those changes that
> have been "considered and approved".
>
>
> Gwendal, no one saying that new syntax is better, that it is good thing
> that we lost the short syntax for tuple argumment deconstructions in
> closures.
>
>
> Good to hear :-)
>
> But there is just no easy/obvious way to keep that syntax in Swift 4. The
> problem can't be solved just by not implementing SE-0110, as in Swift4 we
> should have two separate function types: one that takes single tuple
> argument and second that accepts a list of arguments, i.e. (Int,Int)->()
> and ((Int,Int))->() should be two different types now.
>
>
> Of course I understand that.
>
> I expect the compiler to perform the expected conversions for ergonomics'
> sake.
>
> I can understand that this sugar could be added *after* current problems
> which are not related to ergonomics are solved. I just want to make it
> clear that there is an ergonomics problem *now*, and that solving it should
> have a very high priority.
>

If this was the point you wished to make, then there isn’t any
disagreement, I don’t think. We *all* can obviously agree that there is a
loss in ergonomics due to SE-0110.

This is not just SE-0110, this is also SE-0066, so, to be correct, you
> should propose to revisit it also.
>
> Please look here:
>
> func foo(_ x: Int, _ y: Int) {} // type(of: foo) should be (Int, Int)->()
> func bar(_ x (Int, Int)) {} // type(of: bar) should be ((Int, Int))->()
>
> The above is described in SE-0066. Then, you have a closure constants:
>
> var fooClosure = {(x: Int, y: Int) in }
> var barClosure = {(x: (Int, Int)) in }
>
> what should be types of these closures? Obvious the same: (Int,Int)->()
> and ((Int,Int))->() respectively.
>
>
> I guess you mean, not the same: (Int, Int) -> () vs. ((Int, Int)) -> ().
>
> Then you have a func that accepts ((Int,Int))->Int closure:
>
> func schedule(callback: ((Int,Int))->()) {..}
>
> , given type of foo func is (Int, Int)->() , do you suggest to allow
> sending foo to 'schedule' func? The same question is for fooClosure
>
> schedule(callback: foo) // ??
> schedule(callback: fooClosure) // ??
>
>
> Yes, I do. For ergonomics' sake.
>
> Probably we can(if technically possible, I don't know) to always allow
> sending of function/closure with list of arguments when function with one
> tuple is required. I don't know how such exceptional rule would looks like
> inside type system of Swift, what should be result of 'foo is
> ((Int,Int))->()' then and 'type(of:foo) == type(of:bar)' in such case.
> But this requires a formal proposal, review period and implementation(as I
> understand, better before Swift 4 release). Probably you can submit such
> proposal, go through the review period and help with implementation.
>
>
> Seriously I don't know if I have the skills to write such a proposal. It
> dives much too deep in the compiler internals for me to be efficient in the
> proposal process.
>
> I thus hope that I did succeed showing how seriously bad are the
> regressions induced by SE-0110, and that a skilled language designer will
> sponsor an ergonomics-rescue proposal.
>
> So far, the answer to the ergonomics regression reports have been much too
> often negative. I wish ergonomics had better support in the community. Very
> few regular developers talk here, unfortunately.
>

As I mentioned in a reply above, re-reading SE-0029 gives a full account of
the rationale for this series of proposals. It acknowledges that tuple
splatting is useful and explicitly welcomes a complete design for future
consideration. However, it states that this is *hard*, and that the reason
for not having one is precisely what you said: no one with both the
expertise and the time has stepped forward to do it. Again, I’m not sure
we’re covering new ground here, or even disagreeing.

In this case we'll have the same user-friendly closure/function parameters
> expirience but with respect to correct function types.
>
>
> That would be just great!
>
> But currently we have a situation: argument of type ((Int,Int))->() is
> required, and we provide argument of another type : (Int,Int)->() i.e.
> incorrect type.
>
> The only obvious solution here is using the common rule for type mismatch
> - disallow this.
>
>
> And the obvious and easy way leads to regressions.
>
> Currently we have a number of suggestions how we can improve usability for
> the discussed problem:
>
> * use 'let' syntax in closure argument list to deconstruct tuple argument
>
> * use doubled parenthesis to deconstruct tuple argument: { ((key, value))
> in .. }
>
>
> Both 'let' and doubled parenthesis fail in ergonomics.
>
> Let me explain you why: when you provide a closure to a function, do you
> know if the function expects a single-tuple input, or a multiple-arguments
> input? You don't know.
>

Wait, why don’t you know? This is a baffling statement for me. Of course
you would know, by inspection, surely?

For example, take those three functions:
>
> func f(_ closure:(Int, Int) -> ())
> func g(_ closure:((Int, Int)) -> ())
> func h(_ closure:((a: Int, b: Int)) -> ())
>
> If one can always write (as in Swift 3):
>
> f { (a, b) in ... }
> g { (a, b) in ... }
> c { (a, b) in ... }
>
> Then one can easily deal with a badly fit closure signature.
>
> This is most examplified by dictionaries. They always expose (key: Key,
> value: Value) tuples (their Element type). Problem is that 'key' and
> 'value' are identifiers that only matter for dictionaries, not for
> dictionary users. It's very important for dictionary users to forget about
> tuples, and the `key` and `value` words:
>
> // No pollution
> dictionary.map { (name, score) in ... }
>
> That wish (let one easily deal with a badly fit closure signature) is also
> asked by Stephen Cellis in his functional explorations.
>
> * generation of closure of correct type if closure is declared inside
> function call and arguments have no type annotations, i.e.
>  //schedule(callback: foo) // disallowed, type mismatch
>  //schedule(callback: fooClosure) // disallowed, type mismatch
>
>  // allowed. compiler will generate closure of type ((Int,Int))->() from
> this code
>  schedule { x,y in }
>
>  // type mismatch, this syntax defines closure of (Int,Int)->() type
>  //schedule { (x: Int, y: Int) in }
>
> But because all of this are additional features that can be added later,
> and each required to be reviewed/discussed in details, core team can decide
> to delay such 'fix' for after-release period. Let's wait and see what core
> team had to say about this subject.
>
>
> I can't wait to hear from the core team.
>
> Gwendal
>
> _______________________________________________
> 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/20170607/43094fe4/attachment.html>