> On Feb 14, 2017, at 1:05 PM, Tony Parker <anthony.par...@apple.com> wrote: > > Hi Charles, > > For both this and the Process proposal - why would we not just improve the > API on the existing types instead of renaming them? > > - Tony
1) The Objective-C Foundation isn’t open source. It’s now 14 years since the introduction of NSError, and those types still throw exceptions when they hit runtime errors, despite the community consistently complaining about this during the intervening decade and a half. I just don’t think it’s going to happen. Those of us that asked for the change have mostly given up and resigned ourselves to either writing our own file handle classes or using exception handling for these things years ago (I would presume the problem is backwards compatibility; there might be some legacy code out there that depends on the exceptions being thrown, and that might prevent the change—an issue that doesn’t exist for Swift code, since it can’t catch exceptions). The Swift solution would start from code which is open-source, meaning that implementation could be done by the community, without depending on the Foundation team. 2) For any changes that are made to the API for the Objective-C types, the same changes will have to be made to the corelibs types anyway for cross-platform source compatibility. Presumably, the unimplemented parts in corelibs are going to need to be implemented as well in order for that project to be complete. So why not kill two birds with one stone? Charles
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
