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

[Gwendal Roué]

> Le 9 juin 2017 à 10:07, Mark Lacey <mark.lacey at apple.com> a écrit :
> 
> I’m not trying to argue that it’s impossible to do. I don’t think it’s a good idea at all. That’s subjective. Me saying “that really should be an error” is a subjective statement. I don’t have to say “This is a subjective statement” to make a subjective statement.

Yes, sorry: It's so easy to sound assertive even when we just want to share and communicate opinions.

>> I *do* suggest a specific handling of { _ ... }. I have shown how it can be implemented in a non-ambiguous fashion. 
> 
> Your own comment says this should be considered ambiguous. It’s unambiguous now. What I am asking is how is that an improvement?

I suggest { _ in ... } is ambiguous only in case of function overloading. In this case, you have { (_) in ... } and { (_,_) in ... } for disambiguation:

    func overloaded(_ closure: (Int, Int) -> Int) -> String { return "overloaded 1" }
    func overloaded(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { return "overloaded 2" }
    overloaded { _ in 1 }      // error: ambiguous use of ‘overloaded'
    overloaded { (_) in 1 }    // "overloaded 1”
    overloaded { (_, _) in 1 } // "overloaded 2”

When a function is not overloaded, then { _ in ... } would always mean "I don't care", and is always accepted except for closures that take no argument at all:

    func f1(_ closure: () -> Int) -> String { return "f1" }
    func f2(_ closure: (Int) -> Int) -> String { return "f2" }
    func f3(_ closure: (Int, Int) -> Int) -> String { return "f3" }
    func f4(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { return "f4" }

    f1 { _ in 1 }      // error

    f2 { _ in 1 }      // OK, you don't care

    f3 { _ in 1 }      // OK, you don't care
    f3 { (_, _) in 1 } // OK, just what I expected!

    f4 { _ in 1 }      // OK, you don't care
    f4 { (_) in 1 }    // OK, just what I expected!
    f4 { (_, _) in 1 } // OK, maybe you use tuple splatting somewhere else and want to be consistent

All this is *possible*. And I don't see how it breaks anything. On the other side, it eases everyday life, reduces clutter, and avoids useless punctuation.
Gwendal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170609/3ebf7bf8/attachment.html>