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

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/-flatten-void.md I think by addressing empty, 1 and n-sized tuples issue

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

> Le 9 juin 2017 à 10:07, Mark Lacey 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 m

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

> On Jun 9, 2017, at 12:55 AM, Gwendal Roué wrote: > >> >> Le 9 juin 2017 à 09:41, Mark Lacey > > a écrit : >> >> >>> On Jun 9, 2017, at 12:12 AM, Gwendal Roué >> > wrote: >>> > func notOverloaded1(_ closure: (Int, Int) -> I

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

> Le 9 juin 2017 à 09:41, Mark Lacey a écrit : > > >> On Jun 9, 2017, at 12:12 AM, Gwendal Roué > > wrote: >> func notOverloaded1(_ closure: (Int, Int) -> Int) -> String { return "notOverloaded1" } func notOverloaded2(_ closure: ((lhs: Int

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

> On Jun 9, 2017, at 12:12 AM, Gwendal Roué wrote: > >>> func notOverloaded1(_ closure: (Int, Int) -> Int) -> String { return >>> "notOverloaded1" } >>> func notOverloaded2(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String >>> { return "notOverloaded3" } >>> >>> func overloa

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

>> func notOverloaded1(_ closure: (Int, Int) -> Int) -> String { return >> "notOverloaded1" } >> func notOverloaded2(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String >> { return "notOverloaded3" } >> >> func overloaded(_ closure: (Int, Int) -> Int) -> String { return >> "over

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

> On Jun 8, 2017, at 11:37 PM, Gwendal Roué via swift-evolution > wrote: > > >> Le 9 juin 2017 à 07:56, Vladimir.S via swift-evolution >> mailto:swift-evolution@swift.org>> a écrit : >> >> Yes, we are discussing the *potential* solutions for Swift 4 that can >> decrease the pain of migratio

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

> Le 9 juin 2017 à 07:56, Vladimir.S via swift-evolution > a écrit : > > Yes, we are discussing the *potential* solutions for Swift 4 that can > decrease the pain of migration of *some* Swift3 code, given (Int,Int)->() and > ((Int,Int))->() are different types in Swift 4. > > But, as was sai

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

On 09.06.2017 4:02, susan.dog...@gmail.com wrote: Vladimir.S via swift-evolution 於 2017年6月9日 上午5:05 寫道： On 08.06.2017 21:17, Gwendal Roué via swift-evolution wrote: Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution mailto:swift-evolution@swift.org>> a écrit : On Jun 7, 2017,

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

> Vladimir.S via swift-evolution 於 2017年6月9日 上午5:05 > 寫道： > > On 08.06.2017 21:17, Gwendal Roué via swift-evolution wrote: >>> Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution >>> mailto:swift-evolution@swift.org>> a écrit : >>> On Jun 7, 2017, at 3:03 AM, Adrian Zubarev vi

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

On 09.06.2017 0:31, Mark Lacey wrote: On Jun 8, 2017, at 2:05 PM, Vladimir.S via swift-evolution mailto:swift-evolution@swift.org>> wrote: On 08.06.2017 21:17, Gwendal Roué via swift-evolution wrote: Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution

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

As a "regular user" I wholeheartedly agree with everything Robert just said. Syntactic consistency between function parameters and closure parameters is a big win for usability and discoverability. I actually did not know that it was possible to destructure tuples in closure arguments before th

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

I’m personally a fan of strictness and maximum consistency. I like the idea of flattening single element tuples down to the deepest thing contained that is not a single element tuple. So (x) flattens to x and x,y flattens to the tuple (x,y). Past SEs have dictated that you may not flatte

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

> On Jun 8, 2017, at 2:05 PM, Vladimir.S via swift-evolution > wrote: > > On 08.06.2017 21:17, Gwendal Roué via swift-evolution wrote: >>> Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution >>> mailto:swift-evolution@swift.org> >>>

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

> On Jun 7, 2017, at 11:12 PM, Stephen Celis via swift-evolution > wrote: > >> On Jun 7, 2017, at 10:33 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> However, what I don’t get is why you’d have a mismatch here. Your method >> `first` accepts a closure, and surely the type it expects sho

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

On 08.06.2017 20:40, Brent Royal-Gordon via swift-evolution wrote: On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution mailto:swift-evolution@swift.org>> wrote: Well please no: 
|let fn2: ((Int, Int)) -> Void = { lhs, rhs in }| Instead use destructuring sugar pitched by Chris Lattn

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

On 08.06.2017 21:17, Gwendal Roué via swift-evolution wrote: Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution mailto:swift-evolution@swift.org>> a écrit : On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution mailto:swift-evolution@swift.org>> wrote: Well please no:

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

Side note: when converting a project to Swift 4, I’ve encountered quite a few Quality of Life regressions that could also be related: Regression 1 When using this library https://github.com/socketio/socket.io-client-swift: public typealias NormalCallback = ([Any], SocketAckEmitter) -> Void cla

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

> On 8 Jun 2017, at 11:17, Gwendal Roué via swift-evolution > wrote: > > >> Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution >> mailto:swift-evolution@swift.org>> a écrit : >> >>> On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution >>> mailto:swift-evolution@swift.o

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

> Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution > a écrit : > >> On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Well please no: >> >> 
>> let fn2: ((Int, Int)) -> Void = { lhs, rhs in } >> >> Instead use d

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

> Le 8 juin 2017 à 20:17, Gwendal Roué a écrit : > > This gives us the ability to deal with unfitted function signatures. For > example, most Dictionary methods. Yes, they are usually unfitted: > > extension Dictionary { > func forEach(_ body: ((key: Key, value: Value)) throws -> V

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

At first glance, this makes totally sense to me, feel free to push this idea on the main discussion thread about this dilemma. :) --  Adrian Zubarev Sent with Airmail Am 8. Juni 2017 um 19:41:03, Brent Royal-Gordon (br...@architechies.com) schrieb: On Jun 7, 2017, at 3:03 AM, Adrian Zubarev

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

> Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution > a écrit : > >> On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Well please no: >> >> 
>> let fn2: ((Int, Int)) -> Void = { lhs, rhs in } >> >> Instead use d

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

On Thu, Jun 8, 2017 at 7:20 PM, Víctor Pimentel Rodríguez via swift-evolution wrote: > > /../ I'm really going to miss being able to model every type of closure > with the type (T) -> U > Me too, and I can also see what you mean regarding the "tone" of some of the proposals. Tuple splat (or rathe

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

> On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution > wrote: > > Well please no: > > 
> let fn2: ((Int, Int)) -> Void = { lhs, rhs in } > > Instead use destructuring sugar pitched by Chris Lattner on the other thread: > > let fn2: ((Int, Int)) -> Void = { ((lhs, rhs)) in } >

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

On Thu, Jun 8, 2017 at 3:01 PM, Vladimir.S wrote: > On 08.06.2017 12:17, Víctor Pimentel Rodríguez via swift-evolution wrote: > >> On Thu, Jun 8, 2017 at 5:15 AM, Susan Cheng via swift-evolution < >> swift-evolution@swift.org > wrote: >> >> Just a thought >>

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

I just want to say, as a "regular developer", that I'm with Vladimir S here. Swift 3 (and current Swift 4) both still have a lot of inconsistencies and/or bugs related to tuple- and function types which will need to be fixed before ABI stability, and they are not fixed by going back to a state wit

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

On 08.06.2017 9:43, Jonathan Hull wrote: Also, I want to repeat what I said on the other thread. We should revert to Swift 3 behavior for this, and then take the time to design the behavior we really want (either for 4.1 or 5). Anything else will cause us to break people’s code twice… Yes, *

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

On Thu, Jun 8, 2017 at 7:53 AM, Vladimir.S wrote: > Xiaodi, I'm interested in your opinion, don't you think that *SE-0066* was > the main proposal that separated (Int,Int)->() and ((Int,Int))->() function > *types*? > (https://github.com/apple/swift-evolution/blob/master/propos > als/0066-standar

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

On 08.06.2017 12:17, Víctor Pimentel Rodríguez via swift-evolution wrote: On Thu, Jun 8, 2017 at 5:15 AM, Susan Cheng via swift-evolution mailto:swift-evolution@swift.org>> wrote: Just a thought if parentheses is important, why the tuples are not? This is stated on the proposal (and

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

Xiaodi, I'm interested in your opinion, don't you think that *SE-0066* was the main proposal that separated (Int,Int)->() and ((Int,Int))->() function *types*? (https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md) 'Proposed solution' section of

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

On Thu, Jun 8, 2017 at 5:15 AM, Susan Cheng via swift-evolution < swift-evolution@swift.org> wrote: > Just a thought > > if parentheses is important, why the tuples are not? > This is stated on the proposal (and not in previous proposals): https://github.com/apple/swift-evolution/blob/master/pro

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

Also, I want to repeat what I said on the other thread. We should revert to Swift 3 behavior for this, and then take the time to design the behavior we really want (either for 4.1 or 5). Anything else will cause us to break people’s code twice… Thanks, Jon > On Jun 7, 2017, at 11:50 AM, Gwen

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

> On Jun 7, 2017, at 11:33 AM, Gwendal Roué via swift-evolution > wrote: > > So far, the answer to the ergonomics regression reports have been much too > often negative. I wish ergonomics had better support in the community. Very > few regular developers talk here, unfortunately. Yes, I unfo

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

that makes sense to me ;P 2017-06-08 12:07 GMT+08:00 Gwendal Roué : > Le 8 juin 2017 à 05:15, Susan Cheng via swift-evolution < > swift-evolution@swift.org> a écrit : > > Just a thought > > if parentheses is important, why the tuples are not? > > var tuple1: (Int, Int) = (0, 0) > var tuple2:

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

> Le 8 juin 2017 à 05:15, Susan Cheng via swift-evolution > a écrit : > > Just a thought > > if parentheses is important, why the tuples are not? > > var tuple1: (Int, Int) = (0, 0) > var tuple2: Int, Int = (0, 0) > > type(of: tuple1) == type(of: tuple2)// true > > var void:

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

if it's necessary to distinct argument list and tuple, what about the enum? enum Foo { case tuple(a: Int, b: Int) } let tuple = Foo.tuple((1, 2)) if case let .tuple(a, b) = tuple { (a, b)// (1, 2) } if case let .tuple(tuple) = tuple { tuple// (1, 2) }

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

On Wed, Jun 7, 2017 at 10:15 PM, Susan Cheng via swift-evolution < swift-evolution@swift.org> wrote: > Just a thought > > if parentheses is important, why the tuples are not? > It is not parentheses that are important; it is the distinction between an argument list and a tuple. They both happen t

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

On Wed, Jun 7, 2017 at 10:12 PM, Stephen Celis wrote: > > On Jun 7, 2017, at 10:33 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > > However, what I don’t get is why you’d have a mismatch here. Your method > `first` accepts a closure, and surely the type it expects s

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

Just a thought if parentheses is important, why the tuples are not? var tuple1: (Int, Int) = (0, 0) var tuple2: Int, Int = (0, 0) type(of: tuple1) == type(of: tuple2)// true var void: ((())) = () type(of: void) == type(of: Void()) // true 2017-06-07 10:15 GMT+08:00

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

> On Jun 7, 2017, at 10:33 PM, Xiaodi Wu via swift-evolution > wrote: > > However, what I don’t get is why you’d have a mismatch here. Your method > `first` accepts a closure, and surely the type it expects should be > `((String, Conversation)) -> Bool` instead, since that is the type that the

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

On Wed, Jun 7, 2017 at 19:15 Víctor Pimentel Rodríguez wrote: > On 7 Jun 2017, at 21:29, Xiaodi Wu wrote: > > > SE-0110 may be an obvious extension of the proposed goal, but it is clear >> that it has been implemented in Swift 4, and that the consequences are >> derived of those changesets. >> >

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

On 7 Jun 2017, at 21:29, Xiaodi Wu wrote: SE-0110 may be an obvious extension of the proposed goal, but it is clear > that it has been implemented in Swift 4, and that the consequences are > derived of those changesets. > > Those "unwanted" consequences can be reverted by temporarily reverting >

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

On 07.06.2017 21:33, Gwendal Roué wrote: Le 7 juin 2017 à 17:15, Vladimir.S mailto:sva...@gmail.com>> a écrit : On 07.06.2017 16:20, Gwendal Roué wrote: Le 7 juin 2017 à 15:11, Xiaodi Wu > a écrit : While SE-0025 was generally regarde

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

On Wed, Jun 7, 2017 at 14:33 Gwendal Roué via swift-evolution < swift-evolution@swift.org> wrote: > Le 7 juin 2017 à 17:15, Vladimir.S a écrit : > > On 07.06.2017 16:20, Gwendal Roué wrote: > > Le 7 juin 2017 à 15:11, Xiaodi Wu mailto:xiaodi...@gmail.com >> a écrit : > > While SE-0025 was genera

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

On Wed, Jun 7, 2017 at 14:13 Víctor Pimentel Rodríguez wrote: > > On 7 Jun 2017, at 18:10, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Wed, Jun 7, 2017 at 10:03 Gwendal Roué wrote: > >> Le 7 juin 2017 à 15:52, Xiaodi Wu a écrit : >> >> Let’s clarify: you just wrot

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

> Le 7 juin 2017 à 20:33, Gwendal Roué a écrit : > > For example, take those three functions: > > func f(_ closure:(Int, Int) -> ()) > func g(_ closure:((Int, Int)) -> ()) > func h(_ closure:((a: Int, b: Int)) -> ()) > > If one can always write (as in Swift 3): > > f {

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

> Le 7 juin 2017 à 17:15, Vladimir.S a écrit : > > On 07.06.2017 16:20, Gwendal Roué wrote: >>> Le 7 juin 2017 à 15:11, Xiaodi Wu >> > a écrit : >>> >>> While SE-0025 was generally regarded as unfortunate, the thousands of >>> emails that followed relitigating it we

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

On 7 Jun 2017, at 18:10, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: On Wed, Jun 7, 2017 at 10:03 Gwendal Roué wrote: > Le 7 juin 2017 à 15:52, Xiaodi Wu a écrit : > > Let’s clarify: you just wrote that you have problems with SE-0029, > SE-0066, SE-0110, and “before,” did

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

On Wed, Jun 7, 2017 at 10:03 Gwendal Roué wrote: > Le 7 juin 2017 à 15:52, Xiaodi Wu a écrit : > > Let’s clarify: you just wrote that you have problems with SE-0029, > SE-0066, SE-0110, and “before,” did you not? > > > WTF? No I did not (citation below)! > > Le 7 juin 2017 à 15:02, Gwendal Roué

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

On 07.06.2017 16:20, Gwendal Roué wrote: Le 7 juin 2017 à 15:11, Xiaodi Wu > a écrit : While SE-0025 was generally regarded as unfortunate, the thousands of emails that followed relitigating it were much, much worse. The removal of implicit tuple splatting, which

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

> Le 7 juin 2017 à 15:52, Xiaodi Wu a écrit : > > Let’s clarify: you just wrote that you have problems with SE-0029, SE-0066, > SE-0110, and “before,” did you not? WTF? No I did not (citation below)! > Le 7 juin 2017 à 15:02, Gwendal Roué a écrit : > >> Le 7 juin 2017 à 14:42, Vladimir.S >

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

On Wed, Jun 7, 2017 at 08:34 Gwendal Roué wrote: > > Le 7 juin 2017 à 15:28, Xiaodi Wu a écrit : > > These *are* changes related to SE-0110, and Chris and others have already > proposed possibilities for sugar that could make this better. That’s > exactly the discussion that was originally start

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

> Le 7 juin 2017 à 15:28, Xiaodi Wu a écrit : > > These *are* changes related to SE-0110, and Chris and others have already > proposed possibilities for sugar that could make this better. That’s exactly > the discussion that was originally started, to be distinguished from the > alternative i

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

On Wed, Jun 7, 2017 at 08:20 Gwendal Roué wrote: > > Le 7 juin 2017 à 15:11, Xiaodi Wu a écrit : > > While SE-0025 was generally regarded as unfortunate, the thousands of > emails that followed relitigating it were much, much worse. > > The removal of implicit tuple splatting, which is *not* SE-

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

> Le 7 juin 2017 à 15:11, Xiaodi Wu a écrit : > > While SE-0025 was generally regarded as unfortunate, the thousands of emails > that followed relitigating it were much, much worse. > > The removal of implicit tuple splatting, which is *not* SE-0110, was approved > on the understanding that i

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

On Wed, Jun 7, 2017 at 08:02 Gwendal Roué via swift-evolution < swift-evolution@swift.org> wrote: > Le 7 juin 2017 à 14:42, Vladimir.S a écrit : > > On 07.06.2017 14:18, Gwendal Roué via swift-evolution wrote: > > Xiaodi, Adrian, you are actively pushing so that something that was > allowed, well

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

> Le 7 juin 2017 à 14:42, Vladimir.S a écrit : > > On 07.06.2017 14:18, Gwendal Roué via swift-evolution wrote: >> Xiaodi, Adrian, you are actively pushing so that something that was allowed, >> well compiled (no runtime issue), and covered actual uses cases, becomes >> forbidden. Without any

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

On Wed, Jun 7, 2017 at 07:40 Stephen Celis wrote: > > On Jun 7, 2017, at 8:27 AM, Xiaodi Wu wrote: > > > > Swift package descriptions make extensive use of enums. For example, > .target(...) is an enum case with an associated value, unless I’m mistaken. > I too got the order of “dependencies” an

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

On 07.06.2017 14:18, Gwendal Roué via swift-evolution wrote: Xiaodi, Adrian, you are actively pushing so that something that was allowed, well compiled (no runtime issue), and covered actual uses cases, becomes forbidden. Without any developer advantage that would somehow balance the change. T

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

> On Jun 7, 2017, at 8:27 AM, Xiaodi Wu wrote: > > Swift package descriptions make extensive use of enums. For example, > .target(...) is an enum case with an associated value, unless I’m mistaken. I > too got the order of “dependencies” and “path” reversed the other day; if > enum associated

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

I disagree it almost feels like a revert of SE–0110. If we had more than only: parentheses (angle) brackets braces A fifth set, that would also look visually fine with tuples. This discussion would not even exist, no matter if the data structure behind the scenes is the same or not. Parameter li

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

On Wed, Jun 7, 2017 at 07:16 Stephen Celis wrote: > > On Jun 7, 2017, at 2:01 AM, Xiaodi Wu wrote: > > > > Those are enums, which were aligned with argument lists instead of > tuples in yet another proposal, SE-0155. > > Can you clarify? I wasn't referring to enums, and SE-0155 starts by > talki

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

> On Jun 7, 2017, at 2:01 AM, Xiaodi Wu wrote: > > Those are enums, which were aligned with argument lists instead of tuples in > yet another proposal, SE-0155. Can you clarify? I wasn't referring to enums, and SE-0155 starts by talking about single enum cases with multiple associated values b

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

( /* two parameters, not a tuple */ (Int, Int) -> Void).self == (( /* one tuple parameter */ (Int, Int)) -> Void).self // BUG, which SE-0110 should have fixed, but still didn't Plus inlined: --  Adrian Zubarev Sent with Airmail Am 7. Juni 2017 um 13:53:08, Gwendal Roué (gwendal.r...@gmail.com)

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

> Le 7 juin 2017 à 13:28, Adrian Zubarev a > écrit : > >> Xiaodi, Adrian, you are actively pushing so that something that was allowed, >> well compiled (no runtime issue), and covered actual uses cases, becomes >> forbidden. Without any developer advantage that would somehow balance the >> c

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

On Wed, Jun 7, 2017 at 06:18 Gwendal Roué wrote: > Xiaodi, Adrian, you are actively pushing so that something that was > allowed, well compiled (no runtime issue), and covered actual uses cases, > becomes forbidden. > To be clear, I’m not pushing to forbid anything at all. SE-0110 prohibited thi

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

--  Adrian Zubarev Sent with Airmail Am 7. Juni 2017 um 13:18:22, Gwendal Roué (gwendal.r...@gmail.com) schrieb: Xiaodi, Adrian, you are actively pushing so that something that was allowed, well compiled (no runtime issue), and covered actual uses cases, becomes forbidden. Without any develop

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

Xiaodi, Adrian, you are actively pushing so that something that was allowed, well compiled (no runtime issue), and covered actual uses cases, becomes forbidden. Without any developer advantage that would somehow balance the change. That's called a regression. And what's the rationale, already?

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

IMO, if tuples and argument lists are to be distinguished in any way, it is imperative that f3(+) and f4(+), and some of your other examples, _not_ work. After all, if a tuple is not an argument list, it should possible to have a function of type ((Int, Int)) -> Int and a function of type (Int, In

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

Answer inlined: Am 7. Juni 2017 um 12:33:51, Gwendal Roué (gwendal.r...@gmail.com) schrieb: Le 7 juin 2017 à 12:03, Adrian Zubarev via swift-evolution a écrit : Well please no: 
 let fn2: ((Int, Int)) -> Void = { lhs, rhs in }  Instead use destructuring sugar pitched by Chris Lattner on the

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

> Le 7 juin 2017 à 12:33, Gwendal Roué a écrit : > > >> Le 7 juin 2017 à 12:03, Adrian Zubarev via swift-evolution >> mailto:swift-evolution@swift.org>> a écrit : >> >> Well please no: >> >> 
>> let fn2: ((Int, Int)) -> Void = { lhs, rhs in } >> >> Instead use destructuring sugar pitched

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

Well I’m clearly against this, it doesn’t hurt to use some more paeans inside a closure to tell the compiler if you want to destructure a tuple or use a single argument for the whole tuple. --  Adrian Zubarev Sent with Airmail Am 7. Juni 2017 um 12:31:47, Susan Cheng (susan.dog...@gmail.com)

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

> Le 7 juin 2017 à 12:03, Adrian Zubarev via swift-evolution > a écrit : > > Well please no: > > 
> let fn2: ((Int, Int)) -> Void = { lhs, rhs in } > > Instead use destructuring sugar pitched by Chris Lattner on the other thread: > > let fn2: ((Int, Int)) -> Void = { ((lhs, rhs)) in } >

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

`((Int, Int)) -> Void` will be same type as `(Int, Int) -> Void` 2017-06-07 18:09 GMT+08:00 Adrian Zubarev : > Keep in mind there is also SE–0111 cometary which promises sugar for > parameter labels for closures: > > // ** > let foo(tuple:): ((Int, Int)) -> Void > > // Sugar for ** > let foo: (tu

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

Replacement for fn4 is just make a tuple inside the closure let workWithTuple: (Int, Int) -> Void = { doSomething(withTuple: ($0, $1)) } 2017-06-07 18:03 GMT+08:00 Adrian Zubarev : > Well please no: > > let fn2: ((Int, Int)) -> Void = { lhs, rhs in } > > Instead use destructuring sugar pitched b

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

Keep in mind there is also SE–0111 cometary which promises sugar for parameter labels for closures: // ** let foo(tuple:): ((Int, Int)) -> Void // Sugar for ** let foo: (tuple: (Int, Int)) -> Void What will happen if you’d always flatten here? --  Adrian Zubarev Sent with Airmail Am 7. Juni

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

Well please no: 
 let fn2: ((Int, Int)) -> Void = { lhs, rhs in } Instead use destructuring sugar pitched by Chris Lattner on the other thread: let fn2: ((Int, Int)) -> Void = { ((lhs, rhs)) in } That’s a correct error: let fn3: (Int, Int) -> Void = { _ in } This should be allowed, because we

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

Argument lists should or shouldn't be tuples. I think the question likes a concept more than a technical question. 2017-06-07 14:56 GMT+08:00 Xiaodi Wu : > On Wed, Jun 7, 2017 at 01:51 Susan Cheng wrote: > >> I don't think it's a roll back change. >> > > Function argument lists were once tuples,

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

I don't think it's a roll back change. The proposal is not proposing allow to reorder the parameters by using the tuple or implicit tuple splat to fit the function parameters. It's just clarify the relationship of tuples and argument lists. as the grammar of Swift 3, it's allowed wrapping the arg

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

On Wed, Jun 7, 2017 at 01:51 Susan Cheng wrote: > I don't think it's a roll back change. > Function argument lists were once tuples, but they have not been for many years. All of the proposals I listed above proceed on the basis that these are not the same. Your proposal says that function argum

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

On Wed, Jun 7, 2017 at 00:39 Stephen Celis wrote: > > On Jun 7, 2017, at 1:05 AM, Xiaodi Wu wrote: > > > > This is not what was meant during discussion about re-evaluating > SE-0110. Tuples already behave as described, but function argument lists > are not tuples and have not been for a very lon

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

> On Jun 7, 2017, at 1:05 AM, Xiaodi Wu wrote: > > This is not what was meant during discussion about re-evaluating SE-0110. > Tuples already behave as described, but function argument lists are not > tuples and have not been for a very long time: see SE-0029, SE-0066. > > Also, consider SE-00

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

This is not what was meant during discussion about re-evaluating SE-0110. Tuples already behave as described, but function argument lists are not tuples and have not been for a very long time: see SE-0029, SE-0066. Also, consider SE-0046, which makes possible labels in single-argument argument lis

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

func add2(_ pair: (Int, Int)) -> Int { return pair.0 + pair.1 } consider the follows let _add2 = add2 // add2 have the typeof `((Int, Int)) -> Int`, it should flatten to `(Int, Int) -> Int` so these two lines are also acceptable [(1, 2)].map(add1) [(1, 2)].map(add2) this proposal is no

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

The inline cases make sense to me, but my concern for ambiguity are because we can define both of these functions: func add1(_ x: Int, _ y: Int) -> Int { return x + y } func add2(_ pair: (Int, Int)) -> Int { return pair.0 + pair.1 } // What's the behavior here?

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

a PR is create: https://github.com/apple/swift-evolution/pull/722 2017-06-07 10:15 GMT+08:00 Susan Cheng : > Introduction > > Because the painful of SE-0110, here is a proposal to clarify the tuple > syntax. > > Proposed solution > 1. single element tuple always be flattened > > let tuple1: (((In

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

I like this a lot, but how do we solve for the function case? func add(_ x: Int, _ y: Int) -> Int { return x + y } [(1, 2)].map(add) Where does `map` with a function of `((Int, Int)) -> Int` fit in? > On Jun 6, 2017, at 10:15 PM, Susan Cheng via swift-evolution > wrote: > >

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

[(1, 2)].map({ x, y in x + y }) // this line is correct [(1, 2)].map({ tuple in tuple.0 + tuple.1 }) // this line should not accepted or [(1, 2)].map({ $0 + $1 }) // this line is correct [(1, 2)].map({ $0.0 + $0.1 }) // this line should not accepted it's because `((Int, Int)) -> Int` alw

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

it's also clear that these code will never be ambiguous [(1, 2)].map({ $0 }) // $0 always not a tuple, because arguments should be flattened 2017-06-07 11:21 GMT+08:00 Susan Cheng : > [(1, 2)].map({ x, y in x + y }) // this line is correct > [(1, 2)].map({ tuple in tuple.0 + tuple.1 }) // t

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

Introduction Because the painful of SE-0110, here is a proposal to clarify the tuple syntax. Proposed solution 1. single element tuple always be flattened let tuple1: (((Int))) = 0 // TypeOf(tuple1) == Int let tuple2: Int))), Int) = (0, 0) // TypeOf(tuple2) == (Int, Int) 2. function arg