> Le 9 juin 2017 à 10:07, Mark Lacey <mark.la...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
