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
>
> 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.
···
> Le 9 juin 2017 à 10:07, Mark Laceymailto:mark.lacey@apple.com'> mailto:mark.lacey@apple.com <mark.lacey@apple.com>)>a écrit :
Gwendal
—
very short reply expected - vsre.info
Jérémie Girault
