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

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

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é >>

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" }

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" } >>>

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 >>

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 >> > a écrit : >> >> Yes, we are discussing the *potential*

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

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

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 > 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

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

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 >>>

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 >>

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 > wrote: Well please no: 
|let fn2: ((Int, Int)) -> Void = { lhs, rhs in }| Instead use destructuring

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 > a écrit : On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution

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

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 >> > a écrit : >> >>> 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 >> > wrote: >> >> Well please no: >> >> 
>> let fn2:

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,

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 >> > wrote: >> >> Well please no: >> >> 
>> let fn2:

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

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)) ->

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: >> >>

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

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

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 > wrote: Just a thought if parentheses is important, why the tuples are not? This is

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

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):

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,

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,

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) =

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)

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

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

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,

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

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

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 > a écrit : On 07.06.2017 16:20, Gwendal Roué wrote: Le 7 juin 2017 à 15:11, Xiaodi Wu > a

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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 >>

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

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;

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

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

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

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é

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

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

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

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,

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,

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

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 >> > a écrit : >> >> Well please no: >> >> 
>> let fn2: ((Int, Int)) -> Void = { lhs, rhs

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)) ->

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

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

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. >>

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

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

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 >

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. >

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

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

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

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 >

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`

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

[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