Just in case: https://www.openradar.appspot.com/radar?id=5046886029328384
On Wed, Feb 15, 2017 at 1:41 PM, Charles Srstka via swift-evolution < [email protected]> wrote: > On Feb 15, 2017, at 10:52 AM, Tony Parker <[email protected]> > wrote: > > > 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 say, the purpose of > swift-corelibs-foundation is to present a unified API and prevent the need > to fork. That means the best possible solution is to improve the API in > Objective-C (where exceptions-as-control flow is wrong too) first, and then > naturally flow that into Swift. > > Thanks, > - Tony > > > Honestly? I don’t remember. I feel like I would have sometime around 2005 > or 2006 or so, since that’s probably about when this first started > bothering me, but it’s been a decade, so my memory is hazy. I do know that > in the meantime, “considered harmful”-type articles have been written about > these classes, like this one from eight years ago: > > https://mikeash.com/pyblog/friday-qa-2009-11-13-dangerous-cocoa-calls.html > > If you think it will actually prompt someone to change this, I’d be happy > to write up a new one, although I figure it would almost certainly just get > flagged as a duplicate. > > Charles > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
