[swift-evolution] pitch: Unified libc import (again)

[Taylor Swift]

On Thu, Aug 17, 2017 at 11:19 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Thu, Aug 17, 2017 at 22:06 Taylor Swift <kelvin13ma at gmail.com> wrote:
>
>> Okay I can sense this thread getting derailed so I’ll try to address your
>> comments one by one.
>>
>> * stderr should go wherever stdin and stdout go. Since it’d be silly for
>> a function like `print(_:separator:terminator:)` or `
>> readLine(strippingNewline:)` to live anywhere but the standard library,
>> then it stands to reason that the stderr version should also live in the
>> standard library.
>>
>
> FWIW, FileHandle.standardInput, FileHandle.standardError,
> FileHandle.standardOutput, and FileHandle.nullDevice all live in Foundation.
>

Yet, we have print and readLine, but no printError.


>
>
>> * Foundation is “supposed” to be the core library that does these things,
>> but this isn’t a good thing. Rationale:
>>
>>     * Foundation is literally an Objective C framework that’s written
>> with Swift syntax. The classes extend *NSObject*. You use them by
>> *subclassing* them and overriding open methods. This is patently
>> unswifty. Even parts of Foundation that look swifty on the outside (like `
>> URL`) are still backed by NS reference types internally.
>>
>>     * To fix this would require a complete rewrite from the ground up,
>> that’s more than a straight port from the Objective C framework. Many on
>> this list have also expressed desire to use this chance to redesign these
>> APIs. Since we’d basically have to rewrite all of it, any effort to
>> modernize Foundation is basically writing a new core library.
>>
>>     * Even if a piece of Foundation was rewritten like a real Swift
>> library, because of the monolith pattern, you still wind up importing a lot
>> of legacy code that shouldn’t be floating around your project. Using the
>> file system tools shouldn’t change `String`.
>>
>> * Foundation’s file system capabilities are really just a class wrapper
>> around Glibc/Darwin functions. So in a way, Foundation is already a sort of
>> unified import for C, except it brings in a whole load of Objective C cruft
>> with it.
>>
>>     * Logically, this means in terms of the XY problem, Foundation is on
>> the Y side. Foundation is what happens if you rely on Swift’s C interop to
>> get the job done instead of building a true Swift solution, which would
>> involve Swift quarterbacking all the nasty system calls, instead of
>> Glibc/Darwin doing it.
>>
>> In conclusion,
>>
>> * What we need is a modern Swift solution for accessing file systems.
>>
>> * What we have to do right now is leverage Swift’s C interop to use
>> Glibc/Darwin, while handing imports and platform inconsistencies manually.
>>
>> * Eventually, the ideal would be for Swift to handle that in Swift,
>> instead of delegating to a platform-dependent C library, or at least
>> standardize things so that a swifty Swift library imports the right C
>> library for you, and exports a platform-independent set of symbols to the
>> user, or a higher level API.
>>
>> * Foundation is in many ways the worst of both worlds. It handles the
>> Glibc/Darwin import for us, but at the cost of an aging framework that runs
>> against the grain of good Swift design idioms.
>>
>
> As has been stated on this list by the core team, replacing Foundation or
> duplicating its functionality is a non-goal of the Swift project. The major
> focus of several initial proposals, and a considerable amount of effort on
> this list, was precisely to modernize Foundation so as to offer APIs that
> conform to Swift guidelines. This work remains ongoing, as there are a
> number of Foundation value types that have yet to be designed or
> implemented. And there is a whole open source project devoted to Foundation
> becoming a viable cross-platform library.
>
> So given these parameters, let's return to what you are talking about:
> what is deficient about Swift's core file system APIs, and how would you
> suggest that we address these deficiencies, given that the core team has
> stated that it is not up for debate that any such changes would be part of
> Foundation?
>

This probably isn’t the answer you were looking for, but, as explained,
*all* of it is deficient, so long as you still have to subclass FileManager
and catch CocoaErrors. The problem with Foundation is it tries to offer
core library features and support bridging to Cocoa types at the same time.
Those two goals aren’t very compatible. That’s why there’s such a day and
night difference between stdlib and “pure swift” code, and Foundation code.

So, within the parameters, I would suggest

* rewriting the Foundation file system API types as value and protocol
types, retire the delegate-driven pattern, and *drop* ReferenceConvertible
conformance.

    * value types should be trivial value types, with the possible
exception of file streams which need to be closed.

* separate it as much as possible from other Foundation types, so as to
help disentangle the library from NSNumber and Date.

    * inseparable dependencies like URL should also be rewritten as trivial
types. There is no reason for URL to have reference or copy on write
semantics.

* get submodules into Swift so that Foundation can be split into pieces
instead of being imported as a monolith.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170817/6d57f248/attachment.html>