<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap:break-word"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">I think it’s interesting to discuss tuples, especially around 1-sized tuples.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">I also have an issue about 0-sized tuples and drafted a proposal here.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><a href="https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md">https://github.com/jeremiegirault/swift-evolution/blob/master/proposals/NNNN-flatten-void.md</a></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">I think by addressing empty, 1 and n-sized tuples issues we can avoid the regressions of the language and greatly improve swift4</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div class="bloop_container"><div class="bloop_frame"> > > Le 9 juin 2017 à 10:07, Mark <a href="mailto:Laceymailto%3Amark.lacey@apple.com">Laceymailto:mark.lacey@apple.com</a>'><a href="mailto:mark.lacey@apple.com">mailto:mark.lacey@apple.com</a>)>a écrit :<br>> > <br>> > 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.<br>> Yes, sorry: It's so easy to sound assertive even when we just want to share and communicate opinions.<br>> <br>> > > I *do* suggest a specific handling of { _ ... }. I have shown how it can be implemented in a non-ambiguous fashion.<br>> > <br>> > Your own comment says this should be considered ambiguous. It’s unambiguous now. What I am asking is how is that an improvement?<br>> I suggest { _ in ... } is ambiguous only in case of function overloading. In this case, you have { (_) in ... } and { (_,_) in ... } for disambiguation:<br>> <br>> funcoverloaded(_closure: (Int,Int) ->Int) ->String{return"overloaded 1"}<br>> funcoverloaded(_closure: ((lhs:Int, rhs:Int)) ->Int) ->String{return"overloaded 2"}<br>> <br>> <br>> <br>> <br>> overloaded {_in1}// error: ambiguous use of ‘overloaded'<br>> <br>> <br>> <br>> <br>> <br>> overloaded { (_)in1}// "overloaded 1”<br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> overloaded { (_, _)in1}// "overloaded 2”<br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> 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:<br>> <br>> funcf1(_closure: () ->Int) ->String{return"f1"}<br>> funcf2(_closure: (Int) ->Int) ->String{return"f2"}<br>> funcf3(_closure: (Int,Int) ->Int) ->String{return"f3"}<br>> funcf4(_closure: ((lhs:Int, rhs:Int)) ->Int) ->String{return"f4"}<br>> <br>> f1 {_in1}// error<br>> <br>> f2 {_in1}//OK, you don't care<br>> <br>> f3 {_in1}// OK, you don't care<br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> f3 {(_,_)in1}// OK, just what I expected!<br>> <br>> f4 {_in1}// OK, you don't care<br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> f4 {(_)in1}// OK,just what I expected!<br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> f4 {(_,_)in1}// OK, maybe you use tuple splatting somewhere else and want to be consistent<br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> 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.<br>> Gwendal<br>> <br>> <br>> <br>> </div></div><br><div id="bloop_sign_1497180460648329984" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">—</div><div><font face="Helvetica" size="1">very short reply expected - <a href="http://vsre.info">vsre.info</a></font></div><div style="font-family:helvetica,arial;font-size:13px">Jérémie Girault<br></div></div></body></html>