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?
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 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 <czechb...@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@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@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
