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

Thu Jul 7 01:28:59 CDT 2016

It looks like there are 2 views being discussed

Import System : just masks the difference in platform specific names
Import Libc : a true attempt at a swift specific view of credible c runtime equivalent

The first one would be easy to do now and would alleviate all the mindless #if...#endif we have today.

Regards
LM
(From mobile)

> On Jul 6, 2016, at 1:13 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jul 5, 2016, at 2:59 PM, Brian Gesiak via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Sorry to resurrect such an old thread! I understand getting this in Swift 3.0 might not be realistic anymore, but this is still something I’d love to see added to Swift. Could someone advise on whether it still makes sense to spend time on this proposal? Or is this part of Swift too solidified to change at this point?
>> 
> It is definitely beyond Swift 3.0, but I’d love to see this happen at some point, we really need someone to drive the (surely to be contentious) design process.
> 
> -Chris
> 
> 
>> How much would Libc include? The standard C library? POSIX?
>> 
>> Yes, I had originally anticipated this as including module C and module POSIX. I see that module CUUID was recently added as well, but I don’t think that should be included.
>> 
>> there are differences (minor, but still) between Glibc and Darwin. Those should be either unified (if possible) or re-arranged so that the unified library shares unified functionality and then each separate one can have its own set of caveats.
>> 
>> I don’t think the unified import C module should do anything besides obviate the need to write the following:
>> 
>> #if os(Linux) || os(FreeBSD)
>>     import Glibc
>> #else
>>     import Darwin
>> #endif
>> If people feel strongly about unifying the overlay, perhaps we should discuss that in future swift-evolution proposals.
>> 
>> 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 couldn’t have said it better myself!
>> 
>> /cc Saleem, since he may have Windows opinions.
>> 
>> - Brian Gesiak
>> 
>> 
>>> On Wed, Mar 9, 2016 at 6:35 AM, Honza Dvorsky <czechboy0 at gmail.com> wrote:
>>> 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
>> 
>> _______________________________________________
>> 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/20160707/fda14b22/attachment.html>