[swift-evolution] Proposal: Always flatten the single element tuple

[Jérémie Girault]

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:mark.lacey at apple.com'>
mailto:mark.lacey at apple.com <mark.lacey at 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:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170611/efcb01f7/attachment.html>