Proposal: Always flatten the single element tuple

(Jérémie Girault) #1

I think it’s interesting to discuss tuples, especially around 1-sized
I also have an issue about 0-sized tuples and drafted a proposal here.

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

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


> Le 9 juin 2017 à 10:07, Mark'> <>)>a écrit :

very short reply expected -
Jérémie Girault