Re: [swift-evolution] Pitch: Replacement for FileHandle

FYI, Tony is the manager of the Foundation team. :) We care very much about making sure that the experience of using our framework is a positive one — the more Radars we get, the better we can prioritize improving APIs that are not working as well as they could be for our users. Even if the

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Hi Ben, What’s the use case that you were thinking of? `KeyPath`s could be useful in the case where you don’t need to customize your key names, but cannot represent a custom case like ```swift public struct Post { var authorID: Int var bodyText: String private enum CodingKeys :

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Hi Oliver, Thanks for your comments! We thought about this and we agree overall — we will incorporate this suggestion along with others in the next batch update as long as nothing prohibitive comes up. — Itai On 23 Mar 2017, at 7:49, Oliver Jones wrote: Like everyone I’m excited by this

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

On 15 Mar 2017, at 19:12, Joe Groff wrote: On Mar 15, 2017, at 6:46 PM, Itai Ferber wrote: Thanks Joe, and thanks for passing this along! To those who are curious, we use abstract base classes for a cascading list of reasons: • We need to be able to represent keyed

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

swift-evolution < swift-evolution@swift.org> wrote: On Mar 17, 2017, at 1:15 PM, Itai Ferber via swift-evolution < swift-evolution@swift.org> wrote: On 15 Mar 2017, at 22:58, Zach Waldowski wrote: Another issue of scale - I had to switch to a native mail client as replying inline se

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

On 16 Mar 2017, at 14:29, Matthew Johnson wrote: This is a fantastic proposal! I am very much looking forward to robust Swift-native encoding and decoding in Foundation. The compiler synthesized conformances is especially great!I want to thank everyone who worked on it. It is clear

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

On 15 Mar 2017, at 22:58, Zach Waldowski wrote: Another issue of scale - I had to switch to a native mail client as replying inline severely broke my webmail client. ;-) Again, lots of love here. Responses inline. On Mar 15, 2017, at 6:40 PM, Itai Ferber via swift-evolution <sw

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

I don’t think there’s much of a difference between adding an "optional" primitive (which has a default implementation in terms of a different primitive) and simply having that type adopt `Codable` itself and not be a primitive. You can still switch on the type dynamically (and we do), but you

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

mdiep/status/842178457115230210 Why does the Swift Serialization API proposal use abstract base classes? -Joe On Mar 15, 2017, at 3:40 PM, Itai Ferber via swift-evolution <swift-evolution@swift.org> wrote: Hi everyone, The following introduces a new Swift-focused archival and seriali

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

down there will be when Xcode/SourceKit tries to autocomplete ‘enc’ or ‘dec’ for the Swift Archival & Serialization proposal?) Regards, Will Stanton On Mar 15, 2017, at 6:43 PM, Itai Ferber via swift-evolution <swift-evolution@swift.org> wrote: Hi everyone, This is a companion proposal to the Fo

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Thanks Zach, that's encouraging to hear! Apologies for the original message size — to be honest I didn't realize how large it was myself until my own email was delayed in moderation. I guess, then, **when responding to the original email, please quote only the sections that you are

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

On 17 Mar 2017, at 12:18, Michael Gottesman wrote: On Mar 16, 2017, at 10:23 AM, Joe Groff via swift-evolution wrote: On Mar 16, 2017, at 10:21 AM, Itai Ferber wrote: On 15 Mar 2017, at 19:12, Joe Groff wrote: On Mar 15, 2017, at 6:46 PM,

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

localization. On 15 Mar 2017, at 22:46, Zach Waldowski wrote: Just a little one that came up with when thinking over the companion proposal… see inline. On Mar 15, 2017, at 6:43 PM, Itai Ferber via swift-evolution <swift-evolution@swift.org> wrote: Foundation-Provided Errors

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Thanks for the comments, David. I responded to #2 in a separate email, but wanted to get back to responding to #1. In implementing this, I have had the same thoughts. Ideally, one day, we would be able to migrate the implementation of this away from the compiler to public API (through

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

I’m going to reply to this thread as a whole — apologies if there’s someone’s comment that I’ve missed. This is something that has come up in internal review, and we’ve certainly given it thought. As Zach has already mentioned, the primary concern with overloading based on return type is

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

We’ll keep this in mind. :) On 15 Mar 2017, at 19:58, Will Stanton wrote: Hello Itai, Thanks for your response and its explanations! Agreed that comprehension of multiple formats is important since there are a couple common ways of encoding JSON dates! Still, ISO 8601 appears pretty often

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Thanks for the thorough and detailed review, Brent! Responses inline. On 15 Mar 2017, at 21:19, Brent Royal-Gordon wrote: On Mar 15, 2017, at 3:40 PM, Itai Ferber via swift-evolution <swift-evolution@swift.org> wrote: Hi everyone, The following introduces a new Swift-focused ar

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Subscripts, by the way, would not help here, since they cannot throw. `decode` must be able to throw. [SR-238](https://bugs.swift.org/browse/SR-238?jql=text%20~%20%22subscript%20throw%22); for Apple folks, 28775436. On 16 Mar 2017, at 11:46, Matthew Johnson via swift-evolution wrote: > On Mar

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

On 16 Mar 2017, at 14:48, Matthew Johnson wrote: Thank you again for bringing these great proposals forward! Thanks for reviewing it, and for your comments! I only have a couple of questions about this proposal. I noticed that the types in this proposal don’t conform to Encoder and

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

The sorted order of keys is an implementation detail of `PropertyListSerialization` which `JSONSerialization` does not share. This would require a change in `JSONSerialization`, which is possible, but out of scope for this work specifically. It would have to go through review. [FWIW, the key

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

On 16 Mar 2017, at 15:45, Matthew Johnson wrote: > On Mar 16, 2017, at 5:37 PM, Itai Ferber wrote: On 16 Mar 2017, at 14:48, Matthew Johnson wrote: Thank you again for bringing these great proposals forward! Thanks for reviewing it, and for your comments! I only have

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

On 16 Mar 2017, at 1:00, Brent Royal-Gordon wrote: On Mar 15, 2017, at 3:43 PM, Itai Ferber via swift-evolution <swift-evolution@swift.org> wrote: Hi everyone, This is a companion proposal to the Foundation Swift Archival & Serialization API. This introduces new encoders an

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Hi Slava, Thanks for your comments! On 16 Mar 2017, at 13:50, Slava Pestov wrote: Hi Itai, I’m wondering what the motivation is for keeping this as part of Foundation and not the standard library. It seems like you’re landing an implementation of this in the Foundation overlay on master,

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

If throwing subscripts made it in the Swift 4 timeframe, then we would certainly consider it. On 16 Mar 2017, at 13:19, Matthew Johnson wrote: > On Mar 16, 2017, at 3:01 PM, Itai Ferber wrote: Subscripts, by the way, would not help here, since they cannot throw. decode

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

On 16 Mar 2017, at 13:27, David Hart wrote: > On 16 Mar 2017, at 20:55, Itai Ferber via swift-evolution <swift-evolution@swift.org> wrote: I’m going to reply to this thread as a whole — apologies if there’s someone’s comment that I’ve missed. This is something that ha

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

By stable ordering, you mean dictionaries with keys being output in the order that they were encoded? Potentially, but this would require additional work as neither Swift dictionaries nor `NSMutableDictionary` support this (reasonable seeing as dictionaries are by definition not sorted), and

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

Hi Brent, Thanks for your comments and thorough review! :) Responses inline. On 4 Apr 2017, at 1:57, Brent Royal-Gordon wrote: On Apr 3, 2017, at 1:31 PM, Itai Ferber via swift-evolution <swift-evolution@swift.org> wrote: Hi everyone, With feedback from swift-evolution and addi

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

uot; or "Sequential" both sound fine, even for an encoder that's slot-based instead of NSArchiver-like model. An array is ordered but you don't have to traverse it in order. Best, Zachary Waldowski z...@waldowski.me On Mon, Apr 3, 2017, at 04:31 PM, Itai Ferber via swift-e

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Hi everyone, With feedback from swift-evolution and additional internal review, we've pushed updates to this proposal, and to the Swift Encoders proposal. In the interest of not blowing up mail clients with the full HTML again, I'll simply be

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

> On Apr 4, 2017, at 6:18 PM, Brent Royal-Gordon wrote: > >> On Apr 4, 2017, at 2:43 PM, Itai Ferber > > wrote: >> I like the separation between keyed and unkeyed containers (and I think >> "unkeyed" is a good name, though

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

> On Apr 5, 2017, at 2:29 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Apr 5, 2017, at 1:44 PM, David Hart via swift-evolution >> > wrote: >> For the same reasons, I continue to

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

specifics on this would likely be in line with the rest of resilience plans for Swift in general. It's likely that this could be addressed by a future proposal, as for the time being developers can simply "not hold it wrong" ;) Thanks, -Colin On Wed, Mar 15, 2017 at 6:52 PM Itai Ferb

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Thanks for putting these thoughts together, Jordan! Some additional comments inline. > On Aug 2, 2017, at 5:08 PM, Jordan Rose wrote: > > David Hart recently asked on Twitter > if there was a good > way to add

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

I just mentioned this in my other email, but to point out here: the reason this works in your case is because you adopt these methods as static funcs and can reasonably rely on subclasses of NSData, NSNumber, NSString, etc. to do the right thing because of work done behind the scenes in the

Re: [swift-evolution] [Request for Feedback] Providing defaults for reading and writing.

Hi Wil, Thanks for putting this together! My biggest thought on this is — what does this provide that you can’t already do yourself today? Since you have to go through the work to put together default values and override `init(from:)` and `encode(to:)` to use them, I’m wondering whether this

Re: [swift-evolution] Idea: Use for default implementation of ?

This would be possible, but I have the following concerns about doing something like this: * This would only be available when Foundation is imported (since this would require access to `JSONEncoder`). This could make debugging confusing if you don’t always import Foundation * What do you get

Re: [swift-evolution] Idea: Exposing _JSONEncoder and _JSONDecoder functionality

Hi Morten, This is something we’ve considered adding and may do so in the future — however, this will require additional API review and will not make it in time for the Swift 4.0 release. The usage of `JSONSerialization` as the serialization backend is a current implementation detail, and may

Re: [swift-evolution] [Request for Feedback] Providing defaults for reading and writing.

That’s fair. :) I think in the time frame of Swift 4, this would be too big of an addition and would require more thought, but: 1. When the conditional conformance feature arrives in a future Swift release, a lot of the hacks surrounding `Equatable` can go away here, because we’ll get things

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

Hi Goffredo, Unless I'm misunderstanding what you mean here, this is exactly what we're proposing with the API — anything `Encodable` can encode any type that is `Encodable` as a nested value: ```swift struct Person : Codable { let name: String let address: Address } struct Address

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

To clarify a bit here — this isn’t a "privilege" so much so as a property of the design of these classes. `NSData`, `NSString`, `NSArray`, and some others, are all known as _class clusters_; the classes you know and use are essentially abstract base classes whose implementation is given in

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> On Aug 6, 2017, at 12:58 PM, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On Aug 3, 2017, at 12:05 PM, Itai Ferber via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Thanks for putting

Re: [swift-evolution] [Accepted] SE-0167: Swift Encoders

Hi Johannes, This is implementation detail that is subject to change, but JSONEncoder and JSONDecoder defer to JSONSerialization to provide the actual serialization to and from JSON. Internally, numbers are represented in NSNumber instances until you ask for them on decode, so large integers

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

> On May 15, 2017, at 4:03 PM, Xiaodi Wu via swift-evolution > wrote: > > This is nice. Thanks for taking the time to write it up. I do have some > concerns/questions: > > Do the rules you spell out align with those for Codable? I think it is very > important that

Re: [swift-evolution] [Update] Updates to SE-0166 and SE-0167

? They seem superfluous now, and potentially confusing. Should users call encodeIfPresent/decodeIfPresent or encode/decode with an optional type? Do the have the same semantics? On 23 Jun 2017, at 21:47, Itai Ferber via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org&g

Re: [swift-evolution] [Update] Updates to SE-0166 and SE-0167

er.decodeIfPresent(Prop3Type.self, forKey: .prop3) >> } >> On 23 Jun 2017, at 13:52, David Hart wrote: >> >> There are a lot of great changes here which make sense after the fact. I'll >> try to play around with them. >> >> One thing I'm concerned about:

Re: [swift-evolution] Feedback on SE-0166 and SE-0167

Hi Gwendal, First, thanks for taking the time to adopt some of our new work. Feedback is always good, and we appreciate it. Some comments inline. > On May 26, 2017, at 7:26 AM, Gwendal Roué via swift-evolution > wrote: > > Hello, > > I want to provide real-life

Re: [swift-evolution] Feedback on SE-0166 and SE-0167

Excellent! Glad that ended up working out — looking forward to seeing this improve quality of life for GRDB users and others. :) On 27 May 2017, at 3:40, Gwendal Roué wrote: > Le 27 mai 2017 à 11:59, David Hart a écrit : I didn’t know that was possible either! Really

Re: [swift-evolution] Question regarding SE-0167 Swift Encoders

Hi Gwendal, I hear your frustration. Some comments inline. > On May 31, 2017, at 5:36 AM, Gwendal Roué wrote: > > Itai, > > (This email is not technical) > > I'm not claiming that SE-0166 should be able to address all archival formats. > I've been talking about GRDB

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

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

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

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 >> > wrote: >> >>> >>> Le 8 juin 2017 à

Re: [swift-evolution] Followup after in-the-field feedback for SE-0170

Those cases will produce `nil`. "Should" is a matter of expectation, but I think that it’s reasonable behavior since it feels truer to the intent the `exactly:` methods. On 16 Jun 2017, at 16:23, Jordan Rose via swift-evolution wrote: > On Jun 14, 2017, at 13:59, Philippe Hausler via

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

will be time for at least one round of feedback to be integrated into this functionality. Jon On May 1, 2017, at 12:54 PM, Itai Ferber via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: Hi Goffredo, On Apr 26, 2017, at 2:00 PM, Goffredo Marocc

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

, Itai Ferber via swift-evolution wrote: Yes, this should be true for most types. The compiler derives conformance based on a nested `CodingKeys` type within your `Codable` type. If you do not supply one, it will derive one on your behalf, but if you do provide one, making a naming transition like

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

Hi Goffredo, > On Apr 26, 2017, at 2:00 PM, Goffredo Marocchi wrote: > > Hello Itai, > > Sorry for the confusion, but I understood that the following > >> To answer your second question, the reason is that using the protocol >> implies that all encoders and decoders must

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

ing the key values they are given as-is); the key names are part of the definition of the enum, as declared as part of the type. On 1 May 2017, at 12:04, Itai Ferber via swift-evolution wrote: Yes, this should be true for most types. The compiler derives conformance based on a nested CodingKeys t

Re: [swift-evolution] Question regarding SE-0167 Swift Encoders

Hi Gwendal, There are no stupid questions — everything helps hammer out this API, so I appreciate you taking the time to look at this so deeply. I have to confess that I’m not familiar with this concept, but let’s take a look: ```swift if let valueType = T.self as?

Re: [swift-evolution] [Pitch] DateComponents{Encoding/Decoding}Strategy in JSON{Encoder/Decoder}

Hi Pitiphong, Thanks for taking the time and energy to pitch this, too! If we can find a good solution for matching this up with ISO 8601, and we have high demand for this feature, I think it will be worth reconsidering again in the future. Thanks for the input! — Itai On 8 Sep 2017, at

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

> On Sep 8, 2017, at 12:46 AM, Haravikk via swift-evolution > wrote: > > >> On 7 Sep 2017, at 22:02, Itai Ferber > > wrote: >> >> protocol Fooable : Equatable { // Equatable is just a simple example >> var myFoo:

Re: [swift-evolution] [Pitch] DateComponents{Encoding/Decoding}Strategy in JSON{Encoder/Decoder}

Hi Pitiphong, Thanks for pitching this! My main question here is about the use case. Since encoding/decoding strategies apply to all values in a payload (whether or not those belong to types that you own), they inherently come with some risk. What is the use case in mind for needing to encode

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

I think there is a bit of confusion here as to what code synthesis does — synthesized conformances (whether `Equatable`, `Hashable`, or `Codable`) merely provide default implementations for something which _already_ conforms to one of these protocols; they do not _add_ conformance to types on

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

> On Sep 7, 2017, at 1:43 PM, Haravikk via swift-evolution > wrote: > >> >> On 7 Sep 2017, at 19:36, Tony Allevato > > wrote: >> >> >> >> On Thu, Sep 7, 2017 at 11:18 AM Haravikk via swift-evolution >>

Re: [swift-evolution] [Pitch] DateComponents{Encoding/Decoding}Strategy in JSON{Encoder/Decoder}

Hi Pitiphong, Don’t worry — your original email was clear, and we are on the same page about `Date{En,De}codingStrategy` and `DateComponents{En,De}codingStrategy` being separate things. To clarify my points, though, there are two main things I want to say: 1. I think there is a mismatch here

Re: [swift-evolution] JSONEncoder: Key strategies

Hi Norio, There are two reasons that I think this is valuable over doing something in `CodingKeys`: 1. The definition you give your coding keys affects all encoding formats. JSON is a format where snake_case can be relatively common, so the transformation makes a lot of sense there. For

Re: [swift-evolution] JSONEncoder: Key strategies

Hi Brent, Perhaps the wording would be better phrased as "boundary from non-uppercase-character to uppercase-character", i.e. numbers and Emoji are treated the same as lowercase characters and are included in the original word. The following are [unit test cases from the associated