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