On Tuesday, July 5, 2016, Chris Lattner <clatt...@apple.com> wrote: > > On Jul 5, 2016, at 2:59 PM, Brian Gesiak via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','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. >
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 <czechb...@gmail.com > <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','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 >>> <javascript:_e(%7B%7D,'cvml','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 >>> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');> > https://lists.swift.org/mailman/listinfo/swift-evolution > > > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution