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

OK, understood. Thanks! Zach On Tue, Apr 4, 2017, at 05:53 PM, Itai Ferber wrote: > Hi Zach, > Thanks for your comments! > The type is called "unkeyed", but I assume "nonkeyed" was a typo and > that's what you meant. As far as the phrasing of "ordered" and > "sequential", both sound g

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

Hi Zach, Thanks for your comments! The type is called "unkeyed", but I assume "nonkeyed" was a typo and that's what you meant. As far as the phrasing of "ordered" and "sequential", both sound good, but: 1. The symmetry between "keyed" and "unkeyed" is helpful in creating opposition between t

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

Itai and co: This is a solid improvement. I think it's appropriate to diminish the importance of non-keyed containers. "Nonkeyed" as the name is pretty iffy to me, though, even though I admit it makes the use case pretty clear. "Ordered" or "Sequential" both sound fine, even for an encoder th

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 Archival & Serialization

> On 23 Mar 2017, at 19:37, Ben Rimmington wrote: > >> On 22 Mar 2017, at 17:41, Itai Ferber wrote: >> >> What’s the use case that you were thinking of? KeyPaths could be useful in >> the case where you don’t need to customize your key names, but cannot >> represent a custom case like >> >> p

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

Fantastic. Great to hear. I look forward to reading the revised proposal! Regards > On 24 Mar 2017, at 3:34 am, Itai Ferber wrote: > > 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 batc

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

Let me vote +1 for splitting it. The added conceptual complexity should be minimal, since it is progressively disclosed. You only need to know about codeable, unless you run into the issue where you only want one, at which point stack overflow, etc… will point you to Encodable/Decodable and yo

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

> On 22 Mar 2017, at 17:41, Itai Ferber wrote: > > What’s the use case that you were thinking of? KeyPaths could be useful in > the case where you don’t need to customize your key names, but cannot > represent a custom case like > > public struct Post { > var authorID: Int > var bodyTe

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

Hi Oliver, > On Mar 23, 2017, at 7:55 AM, Oliver Jones via swift-evolution > wrote: > > Like everyone I’m excited by this new proposal. But… > > > protocol Codable: Adopted by types to opt into archival. Conformance may be > > automatically derived in cases where all properties are also Coda

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 ne

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

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

> On 15 Mar 2017, at 22:40, Itai Ferber wrote: > > The following introduces a new Swift-focused archival and serialization API > as part of the Foundation framework. We’re interested in improving the > experience and safety of performing archival and serialization, and are happy > to receive c

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

Hi Itai, On Tue, Mar 21, 2017 at 1:03 PM Itai Ferber wrote: Hi Colin, Thanks for your comments! Are you talking about Codable synthesis, or encoding in general? Yeah, I meant specifically in the case where things are synthesized automatically. As you point out below, if someone implements a cu

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

Hi Colin, Thanks for your comments! Are you talking about `Codable` synthesis, or encoding in general? On 21 Mar 2017, at 8:44, Colin Barrett wrote: Hi Itai, Glad to see these proposal! I'm curious, have you or the other Swift folks thought about how *users* of these new Codable protocols

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

> On Mar 21, 2017, at 11:24 AM, Colin Barrett > wrote: > > I'm not sure I follow. What do you mean "which strategy to use for a given > encoding"? IMO there should be at most one implementation of Coding / > Decoding for a particular type. So the way you'd say "I want to decode a JSON > resp

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

I'm not sure I follow. What do you mean "which strategy to use for a given encoding"? IMO there should be at most one implementation of Coding / Decoding for a particular type. So the way you'd say "I want to decode a JSON response that implements my blog model" would be, reusing the definition fro

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

> On Mar 21, 2017, at 11:00 AM, Colin Barrett via swift-evolution > wrote: > > > > On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > Here's what I mean: Suppose I have a BlogPost model, and I can both fetch and > post BlogPosts

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

On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution < swift-evolution@swift.org> wrote: > > Here's what I mean: Suppose I have a BlogPost model, and I can both fetch > and post BlogPosts to a cross-platform web service, and store them locally. > But when I fetch and post remotely, I ne

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

Hi Itai, Glad to see these proposal! I'm curious, have you or the other Swift folks thought about how *users* of these new Codable protocols will interact with resilience domains? What I mean is that what appear to be private or internal identifiers, and thus changeable at will, may actually be f

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

> On Mar 20, 2017, at 12:31 PM, Itai Ferber wrote: > > 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

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 d

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

Hi Kenny, > On Mar 19, 2017, at 9:53 PM, Kenny Leung via swift-evolution > wrote: > > Hi All. > > Forgive me if I missed it - I haven’t read the proposal in full detail - but > it seems to make no mention of archiving graphs with circular references. Is > this implicitly supported, or explic

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

> On Mar 20, 2017, at 5:34 AM, Brent Royal-Gordon > wrote: > >> On Mar 19, 2017, at 8:19 PM, Matthew Johnson > > wrote: >> >> First, your solution does not allow a user to see a context if they can't >> name the type (you can't get it as Any and use reflection,

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

Sent from my iPad > On Mar 20, 2017, at 1:43 AM, David Hart wrote: > > >> On 20 Mar 2017, at 02:09, Matthew Johnson via swift-evolution >> wrote: >> >> On Mar 19, 2017, at 2:21 PM, Tony Parker wrote: On Mar 19, 2017, at 12:14 PM, Matthew Johnson wrote:

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

> On Mar 19, 2017, at 8:19 PM, Matthew Johnson wrote: > > First, your solution does not allow a user to see a context if they can't > name the type (you can't get it as Any and use reflection, etc). What I meant is that, if you retrieve the context, you know it is of the type you expect. You d

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

> On 17 Mar 2017, at 17:07, Tony Parker wrote: > > Hi Karl, > >> On Mar 17, 2017, at 12:20 AM, Karl Wagner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On 16 Mar 2017, at 21:48, Slava Pestov via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>>

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

> On 20 Mar 2017, at 02:09, Matthew Johnson via swift-evolution > wrote: > > >>> On Mar 19, 2017, at 2:21 PM, Tony Parker wrote: >>> >>> >>> On Mar 19, 2017, at 12:14 PM, Matthew Johnson >>> wrote: >>> >>> >>> >>> Sent from my iPhone >>> On Mar 19, 2017, at 10:47 AM, Tony Parker

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

Hi All. Forgive me if I missed it - I haven’t read the proposal in full detail - but it seems to make no mention of archiving graphs with circular references. Is this implicitly supported, or explicitly unsupported? While we’re at it, my only real exposure to archiving is through Foundation, so

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

Sent from my iPad > On Mar 19, 2017, at 10:19 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Mar 19, 2017, at 9:14 PM, Brent Royal-Gordon >> wrote: >> >>> On Mar 19, 2017, at 5:51 PM, Matthew Johnson wrote: >>> >>> I generally agree with you about c

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

Sent from my iPad > On Mar 19, 2017, at 9:14 PM, Brent Royal-Gordon > wrote: > >> On Mar 19, 2017, at 5:51 PM, Matthew Johnson wrote: >> >> I generally agree with you about casting. However, my dislike isn’t the >> cast itself, but instead it is the lack of a static guarantee. I’m not su

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

> On Mar 17, 2017, at 1:23 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> (Also, is there any sense in adding `Date` to this set, since it needs >> special treatment in many of our formats?) >> >> We’ve considered adding Date to this list. However, this means that any >> format tha

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

> On Mar 19, 2017, at 5:51 PM, Matthew Johnson wrote: > > I generally agree with you about casting. However, my dislike isn’t the cast > itself, but instead it is the lack of a static guarantee. I’m not sure we’ll > find a solution that provides a static guarantee that a required context > e

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

> On Mar 19, 2017, at 2:21 PM, Tony Parker wrote: > > >> On Mar 19, 2017, at 12:14 PM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPhone >> >> On Mar 19, 2017, at 10:47 AM, Tony Parker > > wrote: >> >>> Hi Matthew, Br

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

> On Mar 19, 2017, at 3:38 PM, Brent Royal-Gordon > wrote: > >> On Mar 19, 2017, at 12:21 PM, Tony Parker > > wrote: >>> >>> On Mar 19, 2017, at 12:14 PM, Matthew Johnson >> > wrote: >>> >>> On Mar 19, 2017, at 10:47 AM, Tony Par

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

> On Mar 19, 2017, at 12:21 PM, Tony Parker wrote: >> >> On Mar 19, 2017, at 12:14 PM, Matthew Johnson > > wrote: >> >> On Mar 19, 2017, at 10:47 AM, Tony Parker > > wrote: >> >>> Hi Matthew, Brent, >>> >>> I see why you are askin

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

> On Mar 19, 2017, at 12:14 PM, Matthew Johnson wrote: > > > > Sent from my iPhone > > On Mar 19, 2017, at 10:47 AM, Tony Parker > wrote: > >> Hi Matthew, Brent, >> >> I see why you are asking for this Context parameter, but putting it into the >> basic Co

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

Sent from my iPhone > On Mar 19, 2017, at 10:47 AM, Tony Parker wrote: > > Hi Matthew, Brent, > > I see why you are asking for this Context parameter, but putting it into the > basic Codable protocol introduces too much conceptual overhead. There are too > many benefits to keeping adoption

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

Hi Matthew, Brent, I see why you are asking for this Context parameter, but putting it into the basic Codable protocol introduces too much conceptual overhead. There are too many benefits to keeping adoption to just one protocol, including discoverability, ease of use, reducing the need for ove

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

> On Mar 17, 2017, at 6:15 PM, Brent Royal-Gordon > wrote: > >> On Mar 17, 2017, at 3:35 PM, Matthew Johnson > > wrote: >> >>> In all seriousness, I see the design as very slightly weak, in that it >>> makes it easy to forget to pass a context through, but quite

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

This does work and can be the solution, I suppose, but I was thinking about agreeing upon some convention that could actually make it into the protocols or–at the least–documentation. As it is, the problem creeps up on newcomers and isn't so obvious until you actually have a second version of your

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

> On Mar 17, 2017, at 3:35 PM, Matthew Johnson wrote: > >> In all seriousness, I see the design as very slightly weak, in that it makes >> it easy to forget to pass a context through, but quite acceptable. > > Easy for who? I was not requiring Codable types to thread it through at all. > Th

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

> On Mar 17, 2017, at 5:13 PM, Brent Royal-Gordon > wrote: > >> On Mar 17, 2017, at 2:38 PM, Matthew Johnson > > wrote: >> >>> At a broad level, that's a good idea. But why not provide something more >>> precise than a bag of `Any`s here? You're in pure Swift; y

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

On 17 Mar 2017, at 13:36, Joe Groff wrote: > On Mar 17, 2017, at 12:49 PM, Itai Ferber wrote: 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:

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

> On Mar 17, 2017, at 2:38 PM, Matthew Johnson wrote: > >> At a broad level, that's a good idea. But why not provide something more >> precise than a bag of `Any`s here? You're in pure Swift; you have that >> flexibility. >> >> protocol Codable { >> associatedtype CodingConte

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

Sent from my iPhone > On Mar 17, 2017, at 3:36 PM, Joe Groff via swift-evolution > wrote: > > >> On Mar 17, 2017, at 12:49 PM, Itai Ferber wrote: >> >> On 17 Mar 2017, at 12:18, Michael Gottesman wrote: >> >> >> On Mar 16, 2017, at 10:23 AM, Joe Groff via swift-evolution >> wrote: >>

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

> On Mar 17, 2017, at 3:23 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 16, 2017, at 12:33 PM, Itai Ferber > > wrote: >> Optional values are accepted and vended directly through the API. The >> encode(_:forKey:) methods take optional values directly

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

> On Mar 17, 2017, at 2:42 PM, Itai Ferber wrote: > > 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!

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

> On 17 Mar 2017, at 21:23, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 16, 2017, at 12:33 PM, Itai Ferber wrote: >> Optional values are accepted and vended directly through the API. The >> encode(_:forKey:) methods take optional values directly, and >> decodeIfPresent(_:for

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

> On Mar 17, 2017, at 12:49 PM, Itai Ferber wrote: > > 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: > > >

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

> On Mar 16, 2017, at 12:33 PM, Itai Ferber wrote: > Optional values are accepted and vended directly through the API. The > encode(_:forKey:) methods take optional values directly, and > decodeIfPresent(_:forKey:) vend optional values. > > Optional is special in this way — it’s a primitive par

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

> On Mar 17, 2017, at 12:49 PM, Itai Ferber wrote: > > 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: > > >

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, Itai Ferber wrote: Thanks Joe, and thanks fo

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

Do you mean versions of the format, or versions of your type? If the latter, this can be done on a case-by-case basis, as needed. You can always do something like ```swift struct Foo : Codable { // Name this as appropriate private let jsonVersion = 1.1 } ``` and have it encode as well

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 that

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

> 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, Itai Ferber wrote: >> >> Thanks Joe, and thanks for passing this along! >>

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

> On Mar 16, 2017, at 12:33 PM, Itai Ferber via swift-evolution > wrote: > > This design struck me as remarkably similar to the reflection system and its > `Mirror` type, which is also a separate type describing an original instance. > My question was: Did you look at the reflection system wh

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

Is there any sense of encoding versions (as in, changes to the JSON representation, for instance?) I don't know that it is necessarily a good idea overall but now is the time to consider it. On Fri, Mar 17, 2017 at 2:27 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: >

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

> On Mar 17, 2017, at 1:15 PM, Itai Ferber via swift-evolution > 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 severely broke my webmail client. ;-) > > Again, lots of love here. Respons

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

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

Hi Matt, > On Mar 17, 2017, at 6:39 AM, Matt Diephouse via swift-evolution > wrote: > > I have two related questions: > > 1. Why was Swift 4 chosen as the target release for adding archival and > serialization? > > 2. Given Swift compatibility requirements going forward, how much will th

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

Hi Karl, > On Mar 17, 2017, at 12:20 AM, Karl Wagner via swift-evolution > wrote: > > >> On 16 Mar 2017, at 21:48, Slava Pestov via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi Itai, >> >> I’m wondering what the motivation is for keeping this as part of Foundation

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

I have two related questions: 1. Why was Swift 4 chosen as the target release for adding archival and serialization? 2. Given Swift compatibility requirements going forward, how much will the design of these APIs be able to change? The overall impression I get from the APIs is that they’ve

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

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

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

> On 16 Mar 2017, at 21:48, Slava Pestov via swift-evolution > 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, and

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

> On Mar 16, 2017, at 4:00 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Mar 16, 2017, at 5:54 PM, Ben Rimmington wrote: >> >> On 16 Mar 2017, at 21:14, Matthew Johnson wrote: On Mar 16, 2017, at 4:12 PM, Itai Ferber wrote:

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

Sent from my iPad > On Mar 16, 2017, at 5:54 PM, Ben Rimmington wrote: > > >>> On 16 Mar 2017, at 21:14, Matthew Johnson wrote: >>> >>> On Mar 16, 2017, at 4:12 PM, Itai Ferber wrote: >>> >>> If throwing subscripts made it in the Swift 4 timeframe, then we would >>> certainly consider it.

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

> On 16 Mar 2017, at 21:14, Matthew Johnson wrote: > >> On Mar 16, 2017, at 4:12 PM, Itai Ferber wrote: >> >> If throwing subscripts made it in the Swift 4 timeframe, then we would >> certainly consider it. > > Cool. Any comment from the core team on whether this is a possibility? If > it

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 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 has come up in internal review, and we’ve certain

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

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 that a lot of work went into the proposal. The proposa

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

> On Mar 16, 2017, at 4:18 PM, Philippe Hausler wrote: > > One point of concern with making the implementations rely on that: it would > require any adopter of Codable to be built in swift 4 mode no? it might be > valuable to keep the protocol not requiring Swift 4 to aide in incremental > mi

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

One point of concern with making the implementations rely on that: it would require any adopter of Codable to be built in swift 4 mode no? it might be valuable to keep the protocol not requiring Swift 4 to aide in incremental migration. > On Mar 16, 2017, at 2:14 PM, Matthew Johnson via swift-e

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

> On Mar 16, 2017, at 4:12 PM, Itai Ferber wrote: > > If throwing subscripts made it in the Swift 4 timeframe, then we would > certainly consider it. > Cool. Any comment from the core team on whether this is a possibility? If it is and nobody else wants to write a proposal I would be willin

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 must be able to thro

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

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

Hi Slava, > On Mar 16, 2017, at 1:50 PM, Slava Pestov via swift-evolution > 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 o

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

> On Mar 16, 2017, at 3:27 PM, David Hart wrote: > > >> On 16 Mar 2017, at 20:55, Itai Ferber via swift-evolution >> mailto: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 somet

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

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, and another copy of all the code will have to go into swift-corelibs-foundation. This se

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

> On Mar 16, 2017, at 3:27 PM, Tony Parker wrote: > > >> On Mar 16, 2017, at 1:24 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Mar 16, 2017, at 2:58 PM, David Hart via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>

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

> On 16 Mar 2017, at 20:55, Itai Ferber via swift-evolution > 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 has come up in internal review, and we’ve certainly > given it thought. As Zach has al

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

> On Mar 16, 2017, at 1:24 PM, Matthew Johnson via swift-evolution > wrote: > >> >> On Mar 16, 2017, at 2:58 PM, David Hart via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On 16 Mar 2017, at 19:34, Zach Waldowski via swift-evolution >>> mailto:swift-evolution@swi

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

> On Mar 16, 2017, at 2:58 PM, David Hart via swift-evolution > wrote: > > >> On 16 Mar 2017, at 19:34, Zach Waldowski via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Thu, Mar 16, 2017, at 02:23 PM, Matthew Johnson via swift-evolution wrote: >>> I don’t have an exam

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

> On Mar 16, 2017, at 3:01 PM, Itai Ferber wrote: > > Subscripts, by the way, would not help here, since they cannot throw. decode > must be able to throw. > SR-238 > ; > for Apple folks, 28775436. > They don’t “h

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 reflect

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 Archival & Serialization

> On 16 Mar 2017, at 19:34, Zach Waldowski via swift-evolution > wrote: > > On Thu, Mar 16, 2017, at 02:23 PM, Matthew Johnson via swift-evolution wrote: >> I don’t have an example but I don’t see a problem either. There are two >> options for specifying the return type manually. We can use

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 ambig

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 wrote: Hi everyone, The following introduces a new Swift-focused archival and serialization API as part of

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

> On Mar 16, 2017, at 1:34 PM, Zach Waldowski via swift-evolution > wrote: > > On Thu, Mar 16, 2017, at 02:23 PM, Matthew Johnson via swift-evolution wrote: >> I don’t have an example but I don’t see a problem either. There are two >> options for specifying the return type manually. We can u

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

On Thu, Mar 16, 2017, at 02:23 PM, Matthew Johnson via swift-evolution wrote: > I don’t have an example but I don’t see a problem either. There are > two options for specifying the return type manually. We can use the > signature you used above and use `as` to specify the expected type: > > let

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

> On Mar 16, 2017, at 1:06 PM, David Hart via swift-evolution > wrote: > > > On 16 Mar 2017, at 16:53, Zach Waldowski > wrote: > >>> On Mar 16, 2017, at 3:09 AM, David Hart via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> 2) Libraries like

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

> On 16 Mar 2017, at 16:53, Zach Waldowski wrote: > >> On Mar 16, 2017, at 3:09 AM, David Hart via swift-evolution >> wrote: >> >> 2) Libraries like Marshal (https://github.com/utahiosmac/Marshal) and Unbox >> (https://github.com/JohnSundell/Unbox) don’t require the decoding functions >> to

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

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

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 encoding and decoding

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

> On Mar 16, 2017, at 3:09 AM, David Hart via swift-evolution > wrote: > > 2) Libraries like Marshal (https://github.com/utahiosmac/Marshal > ) and Unbox > (https://github.com/JohnSundell/Unbox ) > don’t require the

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

On Thu, Mar 16, 2017 at 1:45 AM, Zach Waldowski via swift-evolution < swift-evolution@swift.org> wrote: > Holy cow. There's much to digest here (so much so that my initial > response, which quoted its content, was denied by the mailing list). After > an initial reading, I don't just want this now,

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

First of all, great proposal :D Brent, earlier in the thread makes a lot of good points. But I’d still like to discuss two subjects: 1) What makes the proposal really stand on its feet compared to third-party libraries is the compiler generation magic. I feel divided about it. On one hand, thi

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

Sent from my iPhone > On 16 Mar 2017, at 01:18, Joe Groff via swift-evolution > wrote: > > Congrats on getting this out! A question from the field: > > https://twitter.com/mdiep/status/842178457115230210 Why does the Swift > Serialization API proposal use abstract base classes? > Hopefull

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

> On Mar 15, 2017, at 9:19 PM, Brent Royal-Gordon > wrote: > > I think we'd be better off having `encode(_:forKey:)` not take an optional; > instead, we should have `Optional` conform to `Codable` and behave in some > appropriate way. Exactly how to implement it might be a little tricky becaus

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

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 > wrote: > Proposed solution > We will be introducing the followi

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

> On Mar 15, 2017, at 3:40 PM, Itai Ferber via swift-evolution > wrote: > > Hi everyone, > > The following introduces a new Swift-focused archival and serialization API > as part of the Foundation framework. We’re interested in improving the > experience and safety of performing archival and

  1   2   >