[swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

Wed Mar 9 05:35:05 CST 2016

A huge +1 on the proposal, I even have a code snippet to import the
platform-appropriate C library. I try to write every new Swift library
cross-platform-by-default now and this would definitely remove some
friction. Not to mention it would future-proof many libraries which won't
need to be updated when a new Swift platform is added.

Personally, I like "import C", but at the end of the day I'm happy to call
it whatever as long as it solves the problem. I agree with Brian that with
Swift scaling up to 4 or so platforms soon-ish, it's preferable to not put
any extra burden on Swift users if there is an almost-uniform C API which
can be used everywhere.

On Wed, Mar 9, 2016 at 2:03 AM Jordan Rose via swift-evolution <
swift-evolution at swift.org> wrote:

> One of the reasons we haven't picked this *particular* name is if the C
> or C++ committees ever adopted modules. Given that they just got punted
> from C++17, though, maybe that shouldn't hold us back.
>
> Jordan
>
>
> On Mar 8, 2016, at 11:13, Brian Gesiak via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> # Introduction
>
> Currently, cross-platform Swift programs that rely on symbols defined in
> libc (`fputs`, `stderr`, etc.) must all write the same five lines of
> boilerplate code:
>
>     #if os(Linux) || os(FreeBSD)
>         import Glibc
>     #else
>         import Darwin
>     #endif
>
> Instead, I propose the following, which will work on all platforms:
>
>     import Libc
>
> # Motivation
>
> Let's say we wanted to write a program that, on any platform, would print
> "Hello world!" to stderr. We'd probably come up with this:
>
>     #if os(Linux) || os(FreeBSD)
>         import Glibc
>     #else
>         import Darwin
>     #endif
>
>     fputs("Hello world!", stderr)
>
> The first five lines of this program are necessary to import the symbols
> `fputs` and `stderr`. Five lines may not be much, but these come with
> significant drawbacks:
>
> - They must be written in each source file that relies on libc, which is
> tedious.
> - It is subject to frequent change. As Swift is ported to more platforms,
> that initial check must change to `#if os(Linux) || os(FreeBSD) ||
> os(Windows) || os(Android)`, and so on. End users of Swift may not be
> actively involved in its development, and so may be surprised when the
> latest release suddenly necessitates more `os()` conditions.
> - These combined force users to make a conscious decision to write
> cross-platform code--as opposed to simply writing Swift and have it work on
> other platforms seamlessly.
>
> It would be preferable if people writing Swift did not need to check for
> the current `os()` in order to write code that works across platforms.
>
> # Proposed solution
>
> Instead of conditionally importing Darwin or Glibc, I propose the
> following:
>
>     import Libc
>
> This would import whichever libc implementation Swift was compiled with.
> For Ubuntu Linux releases, this would be Glibc. For OS X releases, this
> would be Darwin. For Android (coming soon in
> https://github.com/apple/swift/pull/1442), this would be Bionic.
>
> This saves the end user from writing boilerplate code, and it isolates
> them from the rapid expansion of platforms on which Swift is able to be
> executed.
>
> This idea is not novel: the Swift package manager already defines a "libc"
> package that is essentially the boilerplate `os()` check above:
> https://github.com/apple/swift-package-manager/blob/master/Sources/libc/libc.swift
> .
>
> However, rather than determining which libc implementation to use at
> runtime (like SwiftPM does above), I propose we allow the Swift stdlib to
> be compiled with any arbitrary implementation of libc.
>
> # Detailed design
>
> It's my understanding that the majority of this change would take place in
> the Swift build scripts and CMake modules. Similar to how those scripts
> export a module named "Glibc" on Linux (see stdlib/public/core/Glibc), this
> proposal could be implementing by exporting a "Libc" on all platforms.
>
> This would also be accompanied by a change to the Swift 3 migrator that
> could automatically convert conditional imports of Darwin/Glibc to the new
> `import Libc`.
>
> We must also devise a strategy for the transient rollout period, when
> Swift defines a Libc module, but we don't have an OS X SDK that uses that
> name in the bundled module.map. We can add a compiler hack for that, to
> transparently translate the name.
>
> # Alternatives considered
>
> I believe there are two contentious points to this proposal:
>
> 1. Whether to unify the module name across platforms.
> 2. What to name the module.
>
> Alternatives considered on point #1 (whether to unify) include:
>
> 1a. The status quo: I consider this to be undesirable for the reasons
> stated in "Motivation". To reiterate: the current system forces users to go
> out of their way to write cross-platform Swift code, as opposed to writing
> code that "just works" everywhere.
> 1b. The current Darwin and Glibc modules are a combination of POSIX and
> the C standard library. We could export *two* modules. However I believe
> this introduces additional overhead for users, with only the marginal
> benefit of clean separation between libc and POSIX.
> 1c. A special import statement, defined in the Swift stdlib, that would
> automatically get preprocessed to the five lines of boilerplate shown
> above. This has several downsides, most notably the added complexity to
> Swift syntax.
>
> On point #2 (what to name it), I have spoken with people that raised
> concerns over the name "Libc":
>
> > Another concern is about compatibility with the C++ modules proposal. If
> we want this module name to mean something, it should agree with the C++
> spec.
>
> I don't know which name was chosen in the C++ spec. I've been searching
> WG21 papers with no luck--any advice on how to find out would be
> appreciated!
>
> Aside from the above point, some concrete alternatives for point #2 (what
> to name it) include:
>
> - `import System`: This is better suited to the idea that the module
> contains both POSIX and libc.
> - `import C`: Drop the "Lib"--just "C". It's cleaner. (
> https://www.youtube.com/watch?v=PEgk2v6KntY)
>
> ---
>
> Thanks for taking the time to read this proposal draft! Feedback (on its
> contents or on how to proceed with the evolution proposal process) is
> greatly appreciated.
>
> - Brian Gesiak
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160309/8d71e5a9/attachment.html>