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

Tue Jul 5 19:28:45 CDT 2016

On Tuesday, July 5, 2016, Chris Lattner <clattner at apple.com> wrote:

>
> On Jul 5, 2016, at 2:59 PM, Brian Gesiak via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','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.
>

I'm probably going to regret this, but given that I had originally proposed
this to Brian and would really like to see this happen, what does this
entail?

> -Chris
>
>
> How much would Libc include? The standard C library? POSIX?
>
> Yes, I had originally anticipated this as including module C
> <https://github.com/apple/swift/blob/7b1a8dcf7fbcfd66f029cc5473edef5a08f86602/stdlib/public/Platform/glibc.modulemap.gyb#L29>
> and module POSIX
> <https://github.com/apple/swift/blob/7b1a8dcf7fbcfd66f029cc5473edef5a08f86602/stdlib/public/Platform/glibc.modulemap.gyb#L141>.
> I see that module CUUID was recently added as well
> <https://github.com/apple/swift/pull/3107>, 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
>
> This is about to me made worse with me trying to get Windows support.  How
does this look?

 #if os(Linux) || os(FreeBSD) || os(PS4)
   import Glibc
 #elseif os(macOS) || os(iOS) || os(tvOS) || os(watchOS)
  import Darwin
 #elseif os(Windows) && (_environment(msvc) || _environment(gnu))
  import msvc
 #else
  import glibc
 #endif

>
> If people feel strongly about unifying the overlay, perhaps we should
> discuss that in future swift-evolution proposals.
>
> I would be interested in that as well.

> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160705/d177dc57/attachment.html>