[swift-evolution] [Accepted] SE-0158 Package Manager Manifest API Redesign

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md The review of SE-0158 "Package Manager Manifest API Redesign" ran from March 7 until March 15. The proposal is accepted with the following revisions: – The "To" in "upToNe

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] Revisiting 'T != Type' in where clause

> On Mar 16, 2017, at 8:36 PM, Jaden Geller wrote: > > >> On Mar 16, 2017, at 8:27 PM, Slava Pestov wrote: >> >> Overload resolution has a lot of heuristics, but it’s not magic. It simply >> doesn’t know how to handle this case. >> >> I’d be in favor of consolidating and simplifying the ove

Re: [swift-evolution] Revisiting 'T != Type' in where clause

> On Mar 16, 2017, at 8:27 PM, Slava Pestov wrote: > > Overload resolution has a lot of heuristics, but it’s not magic. It simply > doesn’t know how to handle this case. > > I’d be in favor of consolidating and simplifying the overload resolution > rules, with the goal of disambiguating commo

Re: [swift-evolution] Revisiting 'T != Type' in where clause

> On Mar 16, 2017, at 8:32 PM, Robert Bennett wrote: > > Agreed, I'm fine with a way of achieving this without T != Type. I suppose I > should have made the subject "Fix Swift's type checker in this particular > case". > > I still have trouble figuring out *how* it can correctly handle ambigu

Re: [swift-evolution] Revisiting 'T != Type' in where clause

Agreed, I'm fine with a way of achieving this without T != Type. I suppose I should have made the subject "Fix Swift's type checker in this particular case". I still have trouble figuring out *how* it can correctly handle ambiguity in protocol extensions but be unable to in a "true" (constructib

Re: [swift-evolution] Revisiting 'T != Type' in where clause

Overload resolution has a lot of heuristics, but it’s not magic. It simply doesn’t know how to handle this case. I’d be in favor of consolidating and simplifying the overload resolution rules, with the goal of disambiguating common cases that are currently ambiguous. We might even be able to do

Re: [swift-evolution] Revisiting 'T != Type' in where clause

I would’ve expected overload resolution to pick the “more specific” one in this case without needing any additional constraints… 🤔 > On Mar 16, 2017, at 6:40 PM, Robert Bennett via swift-evolution > wrote: > > Hello, > > This discussion sort of fizzled out when the topic was first introduced.

[swift-evolution] Revisiting 'T != Type' in where clause

Hello, This discussion sort of fizzled out when the topic was first introduced. Joe Groff had asked the following: > Do you have a concrete example where you need this? It'd be good to know > whether the types are ambiguous due to type checker bugs, or whether there's > a principle by which th

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

> On Mar 16, 2017, at 4:18 PM, Itai Ferber wrote: > > Foundation’s common currency type for errors is unequivocally NSError, and > we’re not looking to change that as part of this proposal. > Not in Swift, where it’s unequivocally Error, and errors thrown from Foundation bridge to CocoaError.

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

Sent from my iPad > On Mar 16, 2017, at 5:59 PM, Itai Ferber wrote: > > 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

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 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 a couple of question

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

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

> 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 a couple of questions about this proposal. > > I noticed

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

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

Sorry, I actually meant that keys would be ordered **alphabetically** (as they are with PropertyListSerialization). I'm storing output from JSONSerialization in a git repository, and when I add/remove a single key-value the entire file changes, due to keys being reordered (seemingly at random).

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

Thank you again for bringing these great proposals forward! I only have a couple of questions about this proposal. I noticed that the types in this proposal don’t conform to Encoder and Decoder. Is the plan to have them to provide private conforming types to Codable types they are asked to enc

Re: [swift-evolution] Swift's reflection

Adding write reflection to the existing Mirrors implementation should not be too difficult and we would accept a well-written PR that adds this capability. Slava > On Mar 15, 2017, at 8:10 AM, Dimitri Racordon via swift-evolution > wrote: > > Hello fellow evolutionists, > > I’d like to ask i

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

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 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 wrote: Hi everyone, This is a companion proposal to the Foundation Swift Archival & Serialization API. This introduces new encoders and decoders to be used as part of this syste

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

Foundation’s common currency type for errors is unequivocally `NSError`, and we’re not looking to change that as part of this proposal. Reusing errors from the Cocoa domain has always been a reasonable choice for 3rd-party developers, and we’d like to keep doing this. We are looking to improve

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] UInt64 indices broken

> On Mar 15, 2017, at 9:04 PM, G Alexander via swift-evolution > wrote: > > All, > > Why does swift fails to fully implement UInt in any object, arrays, sequence, > range, etc > > Initializer for Range, from "http://swiftdoc.org/v3.1/type/Range/"; > > For example, passing a closed range wi

Re: [swift-evolution] UInt64 indices broken

This is a deliberate design choice. As written in The Swift Programming Language: "Use UInt only when you specifically need an unsigned integer type with the same size as the platform’s native word size. If this is not the case, Int is preferred, even when the values to be stored are known to be n

[swift-evolution] UInt64 indices broken

All, Why does swift fails to fully implement UInt in any object, arrays, sequence, range, etc Initializer for Range, from "http://swiftdoc.org/v3.1/type/Range/"; For example, passing a closed range with an upper bound of Int.max triggers a runtime error, because the resulting half-open range

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 Encoders

Could the `JSONEncoder.OutputFormatting.prettyPrinted` case include the **stable ordering** of keys? -- Ben ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/

[swift-evolution] [Draft] extend API for managing tail-allocated buffers

Hi there, I've written up a proposal and would love to hear your feedback on it! Best Regards, Alex Komnin P.S. Based on discussion in https://lists.swift.org/pip ermail/swif

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 Encoders

> On Mar 15, 2017, at 3:43 PM, Itai Ferber via swift-evolution > wrote: > > Hi everyone, > This is a companion proposal to the Foundation Swift Archival & Serialization > API. This introduces new encoders and decoders to be used as part of this > system. > The proposal is available online and

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