[swift-evolution] Pitch: Replacement for FileHandle

[Tony Parker]

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

> On Feb 14, 2017, at 12:46 PM, Charles Srstka <cocoadev at charlessoft.com> wrote:
> 
>> On Feb 14, 2017, at 1:05 PM, Tony Parker <anthony.parker at apple.com <mailto:anthony.parker at 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170215/eaeb7edd/attachment.html>