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 > > wrote: > I was quite surprised to learn that it’s possible to create Swift strings

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,

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

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

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

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

will remain a class type, at least 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,

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

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

[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] Mutability for Foundation types in Swift

ft actually still works on this class type. - Tony > >> On Apr 22, 2016, at 12:18 PM, Tony Parker via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Dear swift-evolution denizens, >> >> As you know

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

ully) easier to 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 exte

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

use them, but still provide the benefits 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 >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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

[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

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

of Foundation in a way that fits in 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 >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: &

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

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

ike >>>> alternative, or will be incrementally reworked, I think it makes sense 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 original

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

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…

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

ry day feel native and natural in Swift. I’ll 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, - To

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,

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

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

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.

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

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

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

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

Hi Andy, > On Sep 2, 2016, at 1:08 PM, Andrew Trick <atr...@apple.com> wrote: > >> >> On Sep 2, 2016, at 9:31 AM, Tony Parker via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Hi Andy, Dav

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

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

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

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

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

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

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

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

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 >> > wrote: >> >> Hi Itai, >> >> I’m wondering what

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

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

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 >> > wrote: >> >> >>> On 16 Mar 2017, at 19:34, Zach

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

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

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 >

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 <br...@architechies.com> > wrote: > >> On Apr 20, 2017, at 10:08 AM, Tony Parker via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> &g

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,

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

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

Hi Karl, > On Apr 22, 2017, at 6:23 AM, Karl Wagner <razie...@gmail.com> wrote: > >> >> On 20 Apr 2017, at 19:08, Tony Parker via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Hi everyone, &

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

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

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

ny > On Apr 26, 2017, at 9:26 AM, Shawn Erickson <shaw...@gmail.com> 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

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

[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

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

Re: [swift-evolution] Revisiting SE-0110

est Regards, Pavel. Well, frankly, I don’t think we should ship with such a 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

Re: [swift-evolution] Revisiting SE-0110

ert it until we > have time to reconsider the fallout? > > There is a migrator support, and I've made a couple of diagnostic > 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 > implement

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

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 >> > wrote: >> On Mon, May 29, 2017 at 10:47 PM,

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:

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

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

Re: [swift-evolution] JSONEncoder: Key strategies

We talked about this a bit, and while 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 P

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

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