> On Jul 5, 2016, at 2:59 PM, Brian Gesiak via swift-evolution > <swift-evolution@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 > <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 > <mailto: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 <mailto: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 <mailto: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 >> <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 >> >> <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 >> <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 <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
