Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

:D Great example for what I was trying to say. We can compose such a thing with existing code and not require an overload per. > On Jun 8, 2017, at 12:34 AM, Susan Cheng wrote: > > this work, > > prefix operator * > > prefix func *(keyPath: KeyPath

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

this work, prefix operator * prefix func *(keyPath: KeyPath) -> (Root) -> Value { return { $0[keyPath: keyPath] } } ["Hello, World"].map(*\String.count)// [12] 2017-06-08 12:19 GMT+08:00 Paul Cantrell via swift-evolution < swift-evolution@swift.org>: >

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

It should be possible to achieve Ruby-like generality in Swift with a protocol for “thing that can converted to a transform function.” That wouldn’t need a special & operator. Here’s a sketch. This sketch doesn’t compile — maybe not enough of Swift 4 is there yet for it to work, or maybe I am

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] Pitch: Support for map and flatMap with smart key paths

-1 A -1 from me may be surprising. I'm excited about key path composition and generic solutions, e.g. this experiment with lenses: https://twitter.com/stephencelis/status/863916921577758721 But I'd prefer a reusable solution for converting key paths into functions. Heaven help me for this

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] Pitch: Support for map and flatMap with smart key paths

+1, I really like this. It would also align nicely with the method type flattening in SE-0042 (once it gets implemented), because passing keypaths (i.e., unbound property references) and unbound

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] Pitch: Support for map and flatMap with smart key paths

+1. Would think that all variants should exist on Optional too unless it would be harmful. On Wed, Jun 7, 2017 at 20:13 Michael J LeHew Jr via swift-evolution < swift-evolution@swift.org> wrote: > This is a great idea, and ought to be easy enough to bring forward! +1 > from me! > > -Michael > >

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

This is a great idea, and ought to be easy enough to bring forward! +1 from me! -Michael > On Jun 7, 2017, at 11:18 AM, Matt Diephouse via swift-evolution > wrote: > >  > >> On Jun 7, 2017, at 10:35 AM, Adam Sharp via swift-evolution >>

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

[swift-evolution] History and future of Swift's parentheses

Swift uses parentheses for a lot of different things (tuples, parameters, calls, grouping, pattern matching, etc), this has led to some confusion, for both language designers and users. Here's a practical introduction that is possibly worth more than a thousand words (or perhaps even swift-evo

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] Pitch: Support for map and flatMap with smart key paths

 > On Jun 7, 2017, at 10:35 AM, Adam Sharp via swift-evolution > wrote: > > The new smart key path feature is really lovely, and feels like a great > addition to Swift. > > It seems like it might be straightforward to add overloads of `map` and > `flatMap` to the

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

On Wed, Jun 7, 2017 at 7:35 PM, Adam Sharp via swift-evolution < swift-evolution@swift.org> wrote: > The new smart key path feature is really lovely, and feels like a great > addition to Swift. > > It seems like it might be straightforward to add overloads of `map` and > `flatMap` to the standard

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

[swift-evolution] Pitch: Support for map and flatMap with smart key paths

The new smart key path feature is really lovely, and feels like a great addition to Swift. It seems like it might be straightforward to add overloads of `map` and `flatMap` to the standard library to make use of the new functionality: let managers = flatOrganisation.managers

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] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

> On Mar 20, 2017, at 11:39 AM, Jon Shier via swift-evolution > wrote: > > So when is this transition happening? The sooner the better, as Mail > can’t really handle threads with large messages, like the recent evolution > threads about Foundation

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] Plan to move swift-evolution and swift-users mailing lists to Discourse

Any update to this? I was hoping for a global announcement at WWDC to attract more folks to join the discussions, but this didn’t happen. --  Adrian Zubarev Sent with Airmail Am 10. Februar 2017 um 07:11:34, Bouke Haarsma via swift-evolution (swift-evolution@swift.org) schrieb: A big +1 for

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 >