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

2017-06-08 Thread Mark Lacey via swift-evolution
> 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

2017-06-08 Thread Gwendal Roué via swift-evolution
> 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] Int indexing into UTF16View

2017-06-08 Thread Félix Cloutier via swift-evolution
It's not. Static strings use UTF-8. > Le 8 juin 2017 à 16:38, David Hart via swift-evolution > a écrit : > > > >> On 8 Jun 2017, at 14:15, Vladimir.S wrote: >> >>> On 08.06.2017 20:32, David Hart via swift-evolution wrote: >>> Hello, >>> When working with Strings which are known to be ASCII

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

2017-06-08 Thread Vladimir.S via swift-evolution
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,

[swift-evolution] Pitch: Documentation access from the Swift REPL

2017-06-08 Thread Roope Kangas via swift-evolution
I am new to Swift and just started learning but... When exploring standard library and the language it self from the REPL. Users currently need to switch between a browser to read documentation and the REPL it self. What I would like to see in the REPL is behaviour like this: 1> :help print

Re: [swift-evolution] Introduction of OrderedSet

2017-06-08 Thread Jeff Kelley via swift-evolution
I would be in favor of it; there have been a few times (including Core Data, as you mentioned) where I would have used it had it been available. Jeff Kelley slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org > On Jun 7, 2017, at 2:1

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

2017-06-08 Thread Greg Parker via swift-evolution
> On Jun 8, 2017, at 5:09 AM, Gor Gyolchanyan via swift-evolution > wrote: > > 1. Arbitrary `self` Assignments In Intializers > > The first ideas is to allow `self = nil` inside failable initializers > (essentially making `self` look like `inout Self?` instead of `inout Self` > with magical

[swift-evolution] Pitch: Limit typealias extensions to the typealias

2017-06-08 Thread Yvo van Beek via swift-evolution
Typealiases can greatly reduce the complexity of code. But I think one change in how the compiler handles them could make them even more powerful. Let's say I'm creating a web server framework and I've created a simple dictionary to store HTTP headers (I know that headers are more complex than tha

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

2017-06-08 Thread Matt Diephouse via swift-evolution
💯 > 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 standard library to make us

[swift-evolution] Introduction of OrderedSet

2017-06-08 Thread Maik Koslowski via swift-evolution
Hello, in the past there have been a few requests for an OrderedSet implementation in Swift. In the proposal https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md was mentioned that the OrderedSet will be considered for the feature. However, sin

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

2017-06-08 Thread Susan Cheng via swift-evolution
> 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] Int indexing into UTF16View

2017-06-08 Thread David Hart via swift-evolution
> On 8 Jun 2017, at 14:15, Vladimir.S wrote: > >> On 08.06.2017 20:32, David Hart via swift-evolution wrote: >> Hello, >> When working with Strings which are known to be ASCII, I tend to use the >> UTF16View for the performance of random access. > > About the performance. Do we have a guaran

Re: [swift-evolution] Int indexing into UTF16View

2017-06-08 Thread David Hart via swift-evolution
> On 8 Jun 2017, at 14:11, Xiaodi Wu wrote: > > At some point–although it’s unclear if it’s still the case after the recent > String revisions–it was the case that Foundation extended String to allow > integer subscripting of UTF16View. > > The issue with offering it generally is that it does

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

2017-06-08 Thread Vladimir.S via swift-evolution
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

2017-06-08 Thread Noah Desch via swift-evolution
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

[swift-evolution] Fortran arrays and my recent proposal

2017-06-08 Thread Daryle Walker via swift-evolution
My array proposals included some form of specifying storage ranks for each extent. By default, the ranks would follow row-major order, like C. The first dimension would have the widest span between elements that differ by 1 in the first index and are the same for other indexes. The last dimensio

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

2017-06-08 Thread Robert Bennett via swift-evolution
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

2017-06-08 Thread Mark Lacey via swift-evolution
> 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

2017-06-08 Thread Daryle Walker via swift-evolution
> 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

2017-06-08 Thread Vladimir.S via swift-evolution
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] Int indexing into UTF16View

2017-06-08 Thread Xiaodi Wu via swift-evolution
At some point–although it’s unclear if it’s still the case after the recent String revisions–it was the case that Foundation extended String to allow integer subscripting of UTF16View. The issue with offering it generally is that it doesn’t reliably serve any use case. You’re using it for performa

Re: [swift-evolution] Int indexing into UTF16View

2017-06-08 Thread Vladimir.S via swift-evolution
On 08.06.2017 20:32, David Hart via swift-evolution wrote: Hello, When working with Strings which are known to be ASCII, I tend to use the UTF16View for the performance of random access. About the performance. Do we have a guarantee that 'barcode' declared in code and/or containing only ASCI

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

2017-06-08 Thread Vladimir.S via swift-evolution
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

2017-06-08 Thread David Hart via swift-evolution
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] Int indexing into UTF16View

2017-06-08 Thread David Hart via swift-evolution
> On 8 Jun 2017, at 12:35, Tony Allevato wrote: > > It is an extremely rare case for a developer to know a priori what literal > numeric indices should be used when indexing into a string, because it only > applies when strings fall into a very specific format and encoding. > > It's been disc

Re: [swift-evolution] Int indexing into UTF16View

2017-06-08 Thread Tony Allevato via swift-evolution
It is an extremely rare case for a developer to know a priori what literal numeric indices should be used when indexing into a string, because it only applies when strings fall into a very specific format and encoding. It's been discussed before during String-related proposals but AFAIK the core t

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

2017-06-08 Thread David Hart via swift-evolution
> 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

2017-06-08 Thread Gwendal Roué via swift-evolution
> 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

2017-06-08 Thread Gwendal Roué via swift-evolution
> 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

2017-06-08 Thread Adrian Zubarev via swift-evolution
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

2017-06-08 Thread Gwendal Roué via swift-evolution
> 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] Possible issue with SE-0166 Swift Archival & Serialization implementation

2017-06-08 Thread James Froggatt via swift-evolution
> On 8 Jun 2017, at 17:48, Brent Royal-Gordon wrote: > >> On Jun 8, 2017, at 8:27 AM, Gwendal Roué via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> >>> Le 8 juin 2017 à 16:51, James Froggatt via swift-evolution >>> mailto:swift-evolution@swift.org>> a écrit : >>> >>> Here

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

2017-06-08 Thread Jens Persson via swift-evolution
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

2017-06-08 Thread Brent Royal-Gordon via swift-evolution
> 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 } >

[swift-evolution] Int indexing into UTF16View

2017-06-08 Thread David Hart via swift-evolution
Hello, When working with Strings which are known to be ASCII, I tend to use the UTF16View for the performance of random access. I would also like to have the convenience of indexing with Int: let barcode = "M1X/CLEMENT EELT9QBQGVAAMSEZY1353 244 21D 531 10A1311446838” let name = barc

Re: [swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

2017-06-08 Thread Gwendal Roué via swift-evolution
> On Jun 8, 2017, at 9:45 AM, Itai Ferber > wrote: > > Hi Gwendal, > >> On Jun 8, 2017, at 8:27 AM, Gwendal Roué via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> Le 8 juin 2017 à 16:51, James Froggatt via swift-evolution >>> mailto:swift-

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

2017-06-08 Thread Víctor Pimentel Rodríguez via swift-evolution
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

2017-06-08 Thread Jens Persson via swift-evolution
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] Possible issue with SE-0166 Swift Archival & Serialization implementation

2017-06-08 Thread Brent Royal-Gordon via swift-evolution
> On Jun 8, 2017, at 8:27 AM, Gwendal Roué via swift-evolution > wrote: >> >> Le 8 juin 2017 à 16:51, James Froggatt via swift-evolution >> a écrit : >> >> Here, container is stored as a `let` value, and uses reference semantics, >> while the proposal also clearly lists these `encode` method

Re: [swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

2017-06-08 Thread Itai Ferber via swift-evolution
Sorry, meant for that to be a reply-all. > On Jun 8, 2017, at 9:45 AM, Itai Ferber wrote: > > Hi Gwendal, > >> On Jun 8, 2017, at 8:27 AM, Gwendal Roué via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> Le 8 juin 2017 à 16:51, James Froggatt via swift-evolution >>>

Re: [swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

2017-06-08 Thread Itai Ferber via swift-evolution
Hi James, Good catch. This is a holdover from an older version of the proposal, and is now a typo. It should be `var container` — the container can be a `struct`, and shouldn’t require reference semantics. — Itai On 8 Jun 2017, at 7:51, James Froggatt via swift-evolution wrote: I've just be

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

2017-06-08 Thread Adrian Zubarev via swift-evolution
Well I was referring to the title of (1) not to the addition it creates with failable initializers, which I guess is fine by me, but I’d need a more detailed proposal or draft to provide better feedback though. --  Adrian Zubarev Sent with Airmail Am 8. Juni 2017 um 17:51:28, Gor Gyolchanyan

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

2017-06-08 Thread Adrian Zubarev via swift-evolution
Isn’t 1 und 2.1 almost the same stuff? I’ve asked once if there is a chance for Swift to support init(_ other: Self) { self = other } for classes. Joe Groff replied this is called “factory initializer”. This feature is highly needed for all the iOS developers out there who abuse NIBs and create

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

2017-06-08 Thread Gor Gyolchanyan via swift-evolution
The problem is, it's not clear what assumptions the swift compiler may have on the semantics of initializers. There may be aggressive optimizations going on under the hood with the knowledge that the returned type is the static type that is being initialized. This guaranteed lack of polymorphism

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

2017-06-08 Thread Gor Gyolchanyan via swift-evolution
Not exactly. #1 is an addition to the language syntax. It's simply a convenient way of expressing failure in a failable initializer the logic of which is already implemented, while extending the syntax in a way that would require zero effort to enable a potential factory initializers. > On Jun

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

2017-06-08 Thread Gor Gyolchanyan via swift-evolution
To clarify further about DefaultInitializable: An uninitialized variable of a DefaultInitializable type will *only* have its `init()` called if it's accessed before being initialized manually. This will ensure that the variable will never be initialized twice. > On Jun 8, 2017, at 6:20 PM, Gor

Re: [swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

2017-06-08 Thread Gwendal Roué via swift-evolution
> Le 8 juin 2017 à 16:51, James Froggatt via swift-evolution > a écrit : > > I've just been trying out the new Coding protocol, and was rather surprised > when trying to implement the `encode(to encoder: Encoder)` method. > > The Swift evolution proposal provides the following example code: >

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

2017-06-08 Thread Gor Gyolchanyan via swift-evolution
Yeah, it's just a small syntactic sugar that doesn't change the current behavior at all, it merely makes initialization syntax more uniform and consistent. Also, something just occurred to me: When we're dealing with convenience initializers, there's the syntax `self.init(...)`, wouldn't it be

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

2017-06-08 Thread Charles Srstka via swift-evolution
> On Jun 8, 2017, at 9:19 AM, David Sweeris via swift-evolution > wrote: > > #1 & #3 would violate Swift's rule about having to fully initialize all > properties in inits. > > My initial reaction is to like #2, though, assuming I understand it correctly. Assigning things to self can already b

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

2017-06-08 Thread Gor Gyolchanyan via swift-evolution
Could you please elaborate why #1 and #3 would violate the rule? About #1: Currently, before all members are initialized, attempts to call to `super.init` or escape `self` will be met with a compile-time error. The idea behind `self = nil` is to mark the initializer as `going to fail on return`

[swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

2017-06-08 Thread James Froggatt via swift-evolution
I've just been trying out the new Coding protocol, and was rather surprised when trying to implement the `encode(to encoder: Encoder)` method. The Swift evolution proposal provides the following example code: public func encode(to encoder: Encoder) throws { // Generic keyed encoder g

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

2017-06-08 Thread tobias--- via swift-evolution
I had the need for the same thing today and made it as an extension on Sequence. extension Sequence { func map(_ keyPath: KeyPath) -> [T] { return self.map { $0[keyPath: keyPath] } } func flatMap(_ keyPath: KeyPath) -> [T] { return self.flatMap

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

2017-06-08 Thread David Sweeris via swift-evolution
> On Jun 8, 2017, at 05:09, Gor Gyolchanyan via swift-evolution > wrote: > > Disclaimer: I do realize that any of the following ideas may have been > discussed before and/or there might be a good reason for their lack of > implementation, so please go easy in me. 🙂 > > 1. Arbitrary `self` As

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

2017-06-08 Thread Vladimir.S via swift-evolution
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

2017-06-08 Thread Xiaodi Wu via swift-evolution
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

2017-06-08 Thread Vladimir.S via swift-evolution
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

2017-06-08 Thread Vladimir.S via swift-evolution
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

[swift-evolution] [Proposal] Uniform Initialization Syntax

2017-06-08 Thread Gor Gyolchanyan via swift-evolution
Disclaimer: I do realize that any of the following ideas may have been discussed before and/or there might be a good reason for their lack of implementation, so please go easy in me. 🙂 1. Arbitrary `self` Assignments In Intializers The first ideas is to allow `self = nil` inside failable initia

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

2017-06-08 Thread Víctor Pimentel Rodríguez via swift-evolution
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] Pitch: Support for map and flatMap with smart key paths

2017-06-08 Thread Paul Cantrell via swift-evolution
Ah, quite ingenious, Susan! And you made me realize that the only reason my no-operator-needed code didn’t compile is that I had keypath instead of keyPath. So it was indeed “Paul needs to go to sleep now” option, which I will now do. 🙄 P > On Jun 7, 2017, at 11:34 PM, Susan Cheng wrote: >