Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

I was going to write up a detailed response to this as well, but Chris did it for me. In general, I agree that we need the feature. However, I believe that the name “ABI” is too specific and does not accomplish the primary purpose of naming this thing — which is to allow people to understand w

Re: [swift-evolution] Add transformers to Codable

Hi Arsen, What’s the difference between providing a method that takes a transformable object on the keyed container protocol and just transforming it yourself before you encode it? - Tony > On Dec 18, 2017, at 8:51 AM, Arsen Gasparyan via swift-evolution > wrote: > > Hello everyone, > > I’

Re: [swift-evolution] JSONEncoder: Key strategies

hile there are some clever things that are possible, ultimately we felt it made the API too complex. I think we have room to provide the functionality on the enum later if we want (e.g. a function you could call). - Tony > > On 6 Nov 2017, at 20:54, Tony Parker via swift-evolution >

[swift-evolution] JSONEncoder: Key strategies

Hi everyone, While we have no formal process at this time for proposals of changes to Foundation-only code, I would still like to post one that we have run through our internal process here for additional public comment. Link to PR with proposal content: https://github.com/apple/swift-corelibs

Re: [swift-evolution] PITCH: Export _JSONEncoder / _JSONDecoder

Hi Florent, We definitely thought about this while designing the set of types with the Codable proposals. One serious concern was just how much API surface area there already is with Codable. If we open up the internal classes as well, we risk confusing the majority of people who are just adop

Re: [swift-evolution] Support for a KeyCodingStrategy option in JSONEncoder and JSONDecoder

Hi Morten, I’ve actually been working on this same idea already and will have something to propose soon. - Tony > On Oct 19, 2017, at 2:03 AM, Morten Bek Ditlevsen via swift-evolution > wrote: > > Hi all, > At work we have just added Codable support for a whole bunch of model objects > in o

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

Hi Pitiphong, > On Jul 13, 2017, at 12:37 AM, Pitiphong Phongpattranont via swift-evolution > wrote: > > Hi swift-evolution, > > I have a few feedbacks on SE-0166 and SE-0167. I’m a library maintainer of a > Swift library for my company. We’re a payment gateway service and have a wide > rang

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

> On Jun 12, 2017, at 8:32 AM, Ben Rimmington via swift-evolution > wrote: > > The new `JSONSerialization.WritingOptions.sortedKeys` option was mentioned at > WWDC. > > "What's New in Cocoa" [33:03 ... 33:33] > > >

Re: [swift-evolution] Introduction of OrderedSet

This is still something I want to do, but I suspect it will require some coordination work with the NSOrderedSet ref type in Foundation. Also, as Doug says, there is a larger question too of how we make source breaking changes like this in Swift 5 (I think we’re probably out of runway for Swift

Re: [swift-evolution] Revisiting SE-0110

> On May 31, 2017, at 3:53 PM, John McCall wrote: > >> On May 31, 2017, at 3:42 PM, Tony Parker > > wrote: >>> On May 31, 2017, at 1:16 PM, John McCall via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On May 30, 2017, at 7:41 AM, Nevi

Re: [swift-evolution] Revisiting SE-0110

> On May 31, 2017, at 1:16 PM, John McCall via swift-evolution > wrote: > >> On May 30, 2017, at 7:41 AM, Nevin Brackett-Rozinsky via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> On Mon, May 29, 2017 at 10:47 PM, Robert Bennett > > wrote: >> I

Re: [swift-evolution] Revisiting SE-0110

ic > improvements for it, that produce fix-its which are exactly > what you see in the aforementioned PR. Otherwise, I'd defer to Slava, who was > implementor of SE-0110. > The migrator support resulted in the fix-it below, which I believe is a subpar experience for such a core

Re: [swift-evolution] Revisiting SE-0110

glaring usability regression. What’s the mitigation plan? Perhaps we should wholesale revert it until we have time to reconsider the fallout? - Tony > > > >> On May 24, 2017, at 12:12 PM, Tony Parker via swift-evolution >> mailto:swift-evolution@swift.org>>

[swift-evolution] Revisiting SE-0110

Hi everyone, We received a pull request in swift-corelibs-foundation which is apparently in response to a language change for SE-0110. It turns this perfectly reasonable code: -self.forEach { (keyItem, valueItem) in into this: +self.forEach { (arg) in +let (keyIte

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

ny > On Apr 26, 2017, at 9:26 AM, Shawn Erickson wrote: > > Can you ping the list when aspects of this work lands in master? I have real > world code that I want to see how this new stuff shakes out when attempting > to use. > > On Wed, Apr 26, 2017 at 9:24 A

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

Hi Riley, > On Apr 25, 2017, at 6:11 PM, Riley Testut via swift-evolution > wrote: > > I’m sure this has already been discussed, but why are the methods throwing > NSErrors and not Enums? If I’m remembering correctly, the original reason for > this was because this was meant to be a part of F

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

Hi Karl, > On Apr 22, 2017, at 6:23 AM, Karl Wagner wrote: > >> >> On 20 Apr 2017, at 19:08, Tony Parker via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi everyone, >> >> Thanks for your feedback on this proposal

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

Hi Brent, > On Apr 20, 2017, at 11:37 PM, Brent Royal-Gordon > wrote: > >> On Apr 20, 2017, at 10:08 AM, Tony Parker via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> * The above will allow those protocols, plus Encodable, Dec

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

Hi everyone, Thanks for your feedback on this proposal. Based on that plus additional feedback from core team members and others who responded off-thread, we are making the following small adjustments: * KeyedEncoderContainerProtocol, KeyedDecodingContainerProtocol, UnkeyedEncodingContainer, U

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

Hi Rex, > On Apr 10, 2017, at 12:48 PM, Rex Fenley via swift-evolution > wrote: > > Forgive me if I'm missing something, this is a very large proposal and a lot > to parse through. I like how everything is designed as far as I can tell > except I'm not sure from this proposal how one would co

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

Hi David, > On Apr 4, 2017, at 10:33 PM, David Hart via swift-evolution > wrote: > > Very interesting discussion below. Here are a few more points: > > Sent from my iPhone > On 4 Apr 2017, at 23:43, Itai Ferber via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> Hi Brent, >>

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

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

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

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 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] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

I’m concerned about the large source compatibility impact this change would have. Even if we claim that it’s only for Swift 4, migration would be difficult. Even if it were just a warning, that could be extremely noisy for large projects. What do you propose to mitigate that problem? I also th

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

It seems like the main complaints about NSProgress revolve around KVO, which there is no question about not being right for Swift in many ways. I’m aware of that. I think the right answer there is instead to improve KVO in Swift, not to replace all KVO in the SDK on a case-by-case basis with ad-

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

> On Feb 15, 2017, at 2:25 PM, Charles Srstka wrote: > >> On Feb 15, 2017, at 3:11 PM, Itai Ferber > > wrote: >> >> 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 o

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

Hi Charles, Have you happened to file a radar for Foundation that I can look up (for both this and process)? We are working hard on making sure that our API is right for Swift, and areas like this where we can make fairly trivial improvements are things that we can try to prioritize. As you sa

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

> On Feb 14, 2017, at 7:18 AM, Charles Srstka via swift-evolution > wrote: > > MOTIVATION: > > In Swift 3, NSFileHandle was renamed to FileHandle, making it the de facto > file handle class for use in Swift applications. Unfortunately, it’s not a > very good API. NSFileHandle supports no err

Re: [swift-evolution] [Proposal] Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer

Hi Andy, everyone, The short answer is that fixing struct Data requires a source breaking change (the enum for the deallocator has to change to use the raw buffer type), so I do not want to introduce it until Swift 4 provides a better transition path for this kind of change. - Tony > On Jan 4

Re: [swift-evolution] Swift Extensions on Overlay Structs

> On Nov 13, 2016, at 11:43 PM, Fabian Ehrentraud via swift-evolution > wrote: > > That's an interesting idea without having to write type signatures twice. > > The different nullability of the absoluteURL is strange indeed - what if I do > a guaranteed cast from NSURL to URL, and absoluteURL

Re: [swift-evolution] [Discussion] API Guidelines

Hi Adrian, Charlie, One additional thing that we considered when naming methods like this was how central the operation described in the method was to the overall purpose of the type. For example, the core purpose of an array is to store things. Having functions with a base name of ‘add’ or ‘r

Re: [swift-evolution] [swift-evolution-announce] SE-0138 UnsafeBytes

Hi Andy, > On Sep 2, 2016, at 1:08 PM, Andrew Trick wrote: > >> >> On Sep 2, 2016, at 9:31 AM, Tony Parker via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi Andy, Dave, >> >> I have two major objections to this pr

Re: [swift-evolution] [swift-evolution-announce] SE-0138 UnsafeBytes

Hi Andy, Dave, I have two major objections to this proposal. The first is timing. It is too late for us to evaluate this correctly for Swift 3. The second is that this API overlaps too much with Foundation’s struct Data. We should be standardizing on a small number of common types, so that dev

Re: [swift-evolution] [Proposal draft] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

> On Aug 24, 2016, at 11:09 AM, Douglas Gregor wrote: > >> >> On Aug 23, 2016, at 4:00 PM, Tony Parker > > wrote: >> >> Hi Doug, >> >>> On Aug 23, 2016, at 3:36 PM, Douglas Gregor via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Intr

Re: [swift-evolution] [Proposal draft] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

Hi Doug, > On Aug 23, 2016, at 3:36 PM, Douglas Gregor via swift-evolution > wrote: > > Introduction > > A handful of Swift numeric types are bridged to NSNumber when passed into > Objective-C object contexts. We should extend this bridging behavior to all > Swift numeric types. We should al

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced

For what it’s worth, I agree with Dmitri on the naming of this function. I think we should find a way to give it a name without “NonObjC” in it. - Tony > On Jul 20, 2016, at 8:15 AM, Arnold via swift-evolution > wrote: > > > > Sent from my iPhone > >> On Jul 20, 2016, at 6:50 AM, Dave Abra

Re: [swift-evolution] Notification.Name

Hi Brent, In general, I agree with your idea that the scope of the name of these things is with the type it’s used for. The type of it is of course Notification.Name. One thing we did in the short term to make this feature even remotely possible was to add an importer rule: global const NSStrin

Re: [swift-evolution] [swigt-evolution] [Pitch] Make NSOrderedSet behave like any other collections from Foundation

Hi Remy, Brent, We’re thinking about it but there are no plans for Swift 3 in this respect (although I think we’re going to keep the NS prefix on these types). One of the complexities with this type is its performance characteristics, especially when used with CoreData (the reason it was introd

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

Hi everyone, After some discussion, we have a small update to the proposal. The following types will keep their NS prefix: NSCoding NSSecureCoding NSCoder NSKeyedArchiver NSKeyedUnarchiver The reason is that NSCoding is, at least for the moment, fairly tied to Objective-C (since it is partiall

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

> On May 12, 2016, at 1:32 AM, Patrick Smith via swift-evolution > wrote: > > I second Matthew’s points. I believe dropping NS- is more harmful than > helpful, especially for the future. People have been using Foundation with > the prefix for decades, so I don’t think there’s a longing need t

Re: [swift-evolution] Dropping NS Prefix in Foundation

se for >>>> it to feel a little weird to use as it is right now. >>>> >>>> The NS prefix makes it clear that this is something different, something >>>> not originally designed with Swift in mind, and in a way that’s a good >>>>

Re: [swift-evolution] Dropping NS Prefix in Foundation

> On May 7, 2016, at 6:06 AM, Jonathan Hull wrote: > > -1 on this as well. How much does dropping NS really help things anyway? > > All it does is force everyone to learn which things still have NS and which > don’t. It also makes things much more difficult to search for… searching for >

Re: [swift-evolution] Dropping NS Prefix in Foundation

beat the drum of iterative improvement again: the best way to get there from here is to make continuous adjustments and improvements from release to release. You will see the rethinking you are looking for over the course of that process. Thanks, - Tony >> >> David (Hart). >&

Re: [swift-evolution] Dropping NS Prefix in Foundation

ture improvements the same way. We may not even know right now what the most important improvement to Foundation is to make it fit in with Swift 4 or Swift 5. That is why I’m focusing on improving what we have so that we can iterate and improve alongside the language itself. - Tony > D

Re: [swift-evolution] Dropping NS Prefix in Foundation

with the language today while allowing us to iteratively improve it over time. - Tony > >> On May 6, 2016, at 2:52 PM, Tony Parker via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi everyone, >> >> Thanks to all o

[swift-evolution] Dropping NS Prefix in Foundation

Hi everyone, Thanks to all of you for your feedback on SE-0069 (Foundation Value Types). I’m back again with more information on another part of our plan to integrate Foundation API into Swift: dropping the NS prefix. When we originally proposed this as part of the API guidelines document (SE-

Re: [swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

Hi Rod, > On May 4, 2016, at 4:59 AM, Rod Brown wrote: > > > Tony, > > With regard to this proposal, is there any reason that this proposal did not > include an OrderedSet value type? I suspect perhaps this is an oversight? > > - Rod > We considered it, but did not include it in this propo

Re: [swift-evolution] Mutability for Foundation types in Swift

Hi Ben, > On Apr 24, 2016, at 3:51 PM, Ben Rimmington via swift-evolution > wrote: > > 0069-swift-mutability-for-foundation.md> > > The proposal looks great. > > ## Introduction > > Broken link: > > --

Re: [swift-evolution] Mutability for Foundation types in Swift

Hi Brent, Thanks for your feedback! You’ve got some great questions below, I’ll try to answer them as best I can. > On Apr 24, 2016, at 3:44 AM, Brent Royal-Gordon > wrote: > >> We took this feedback seriously, and I would like to share with you the >> start of an important journey for some

Re: [swift-evolution] Mutability for Foundation types in Swift

ast for now. Formatters are part of a public class hierarchy (inheriting from NSFormatter), so if we want to turn them into value types I think we’ll need some additional motivation to change their API surface in this way. Thanks, - Tony > >> On Apr 22, 2016, at 10:18 AM, Ton

Re: [swift-evolution] Mutability for Foundation types in Swift

o both implement > and use :) Thanks for your feedback. For what it’s worth, I’m fully in support of your factory type proposal as well. I think we need it in order to finish a complete implementation of swift-corelibs-foundation, at the very least. We can certainly extend these types to inclu

Re: [swift-evolution] Mutability for Foundation types in Swift

its outlined in the proposal. We’ll continue to iterate and improve over time. Thanks, - Tony > >> On Apr 22, 2016, at 11:18 AM, Tony Parker via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Dear swift-evolution denizens, >> >>

Re: [swift-evolution] Mutability for Foundation types in Swift

ib/public/core/SwiftNativeNSArray.swift#L40 This means that if an Objective-C client calls retain on this object (which is a _SwiftNativeNSData), it actually calls swift_retain, which mutates the Swift ref count. This means that a call to _isUniquelyReferencedNonObjC from Swift actually

[swift-evolution] Mutability for Foundation types in Swift

Dear swift-evolution denizens, As you know from our announcement of Swift Open Source and our work on naming guidelines, one of our goals for Swift 3 is to “drop NS” for Foundation. We want to to make the cross-platform Foundation API that is available as part of swift-corelibs feel like it is

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 13, 2016, at 12:57 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 13 2016, Dave Abrahams wrote: > >>> Reverse is the best opposite we have of advance, so it makes sense to >>> me. >> >> Oh, I get it. >> >>> Or we could use retreat. =) There are other pairs of wor

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 12, 2016, at 3:43 PM, Dave Abrahams via swift-evolution > wrote: > > > Thanks for your review, Tony! > > on Mon Apr 11 2016, Tony Parker > wrote: > >>> On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> Hello Swift

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "A New Model for Collections and Indices" begins now and runs > through April 18th. The proposal is available here: > > > https://github.com/apple/swift-evolution/blo

Re: [swift-evolution] Philosophy question: Foundation and Standard Library

Not that I need to say this, but I’ll chime in anyway with a big +1 to what Chris said. =) Fortunately, the current code owners for swift-corelibs-foundation are the same people that work on Foundation for all of our other platforms. That means we’re in a great position to make Foundation great

Re: [swift-evolution] Testing Assertions

Hi Mohamed, I agree it’s very difficult to test assertions in XCTest today. This approach looks interesting, but I’m not sure how it’s possible to implement within XCTest’s current architecture. Do you have any idea how this would be implemented? - Tony > On Dec 31, 2015, at 1:35 AM, Mohamed

Re: [swift-evolution] Trial balloon: Ensure that String always contains valid Unicode

> On Dec 19, 2015, at 7:59 PM, Dmitri Gribenko wrote: > > On Fri, Dec 18, 2015 at 1:47 PM, Paul Cantrell via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > I was quite surprised to learn that it’s possible to create Swift strings > that do not contain things other than valid Uni