I think it’s interesting to discuss tuples, especially around 1-sized tuples. I also have an issue about 0-sized tuples and drafted a proposal here.
https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md I think by addressing empty, 1 and n-sized tuples issues we can avoid the regressions of the language and greatly improve swift4 > > Le 9 juin 2017 à 10:07, Mark Laceymailto:[email protected]'> mailto:[email protected] <[email protected]>)>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: > > funcoverloaded(_closure: (Int,Int) ->Int) ->String{return"overloaded 1"} > funcoverloaded(_closure: ((lhs:Int, rhs:Int)) ->Int) ->String{return"overloaded 2"} > > > > > overloaded {_in1}// error: ambiguous use of ‘overloaded' > > > > > > overloaded { (_)in1}// "overloaded 1” > > > > > > > > > > > overloaded { (_, _)in1}// "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: > > funcf1(_closure: () ->Int) ->String{return"f1"} > funcf2(_closure: (Int) ->Int) ->String{return"f2"} > funcf3(_closure: (Int,Int) ->Int) ->String{return"f3"} > funcf4(_closure: ((lhs:Int, rhs:Int)) ->Int) ->String{return"f4"} > > f1 {_in1}// error > > f2 {_in1}//OK, you don't care > > f3 {_in1}// OK, you don't care > > > > > > > > > > > > > > > > > > f3 {(_,_)in1}// OK, just what I expected! > > f4 {_in1}// OK, you don't care > > > > > > > > > > > > > > > > f4 {(_)in1}// OK,just what I expected! > > > > > > > > > > > > > > > > > > > > > > f4 {(_,_)in1}// 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 > > > > — very short reply expected - vsre.info Jérémie Girault
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
