<div dir="ltr">I'm definitely a big +1 on this -- and pretty much any other suggestion that makes Swift code more portable and sets up a simple interface so that other platforms can be supported without the addition of more code.<div><br></div><div>A few thoughts to add:</div><div> - 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.</div><div><br></div><div> - I like `import System` myself, for the reasons you mentioned (conveys LibC+POSIX combo)</div><div><br></div><div> - down the line, what are thoughts on getting a more Swift-friendly libC API? (I know Foundation plays this role already, but it'd be nice to have a nice API for system calls without having to worry about maintaining interface with the more-proprietary CoreFoundation)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 8, 2016 at 1:13 PM, Brian Gesiak via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div># Introduction</div><div><br></div><div>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:</div><div><br></div><div> #if os(Linux) || os(FreeBSD)</div><div> import Glibc</div><div> #else</div><div> import Darwin</div><div> #endif</div><div><br></div><div>Instead, I propose the following, which will work on all platforms:</div><div><br></div><div> import Libc</div><div><br></div><div># Motivation</div><div><br></div><div>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:</div><div><br></div><div> #if os(Linux) || os(FreeBSD)</div><div> import Glibc</div><div> #else</div><div> import Darwin</div><div> #endif</div><div><br></div><div> fputs("Hello world!", stderr)</div><div><br></div><div>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:</div><div><br></div><div>- They must be written in each source file that relies on libc, which is tedious.</div><div>- 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.</div><div>- 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.</div><div><br></div><div>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.</div><div><br></div><div># Proposed solution</div><div><br></div><div>Instead of conditionally importing Darwin or Glibc, I propose the following:</div><div><br></div><div> import Libc</div><div><br></div><div>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 <a href="https://github.com/apple/swift/pull/1442" target="_blank">https://github.com/apple/swift/pull/1442</a>), this would be Bionic.</div><div><br></div><div>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.</div><div><br></div><div>This idea is not novel: the Swift package manager already defines a "libc" package that is essentially the boilerplate `os()` check above: <a href="https://github.com/apple/swift-package-manager/blob/master/Sources/libc/libc.swift" target="_blank">https://github.com/apple/swift-package-manager/blob/master/Sources/libc/libc.swift</a>.</div><div><br></div><div>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.</div><div><br></div><div># Detailed design</div><div><br></div><div>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.</div><div><br></div><div>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`.</div><div><br></div><div>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.</div><div><br></div><div># Alternatives considered<br><br>I believe there are two contentious points to this proposal: <br><br>1. Whether to unify the module name across platforms.<br>2. What to name the module.<br><br>Alternatives considered on point #1 (whether to unify) include:</div><div><br></div><div>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.<br></div><div>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.<br>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.<br><br>On point #2 (what to name it), I have spoken with people that raised concerns over the name "Libc":</div><div><br></div><div>> 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.</div><div><br></div><div>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!<br><br>Aside from the above point, some concrete alternatives for point #2 (what to name it) include:</div><div><br></div><div>- `import System`: This is better suited to the idea that the module contains both POSIX and libc.</div><div>- `import C`: Drop the "Lib"--just "C". It's cleaner. (<a href="https://www.youtube.com/watch?v=PEgk2v6KntY" target="_blank">https://www.youtube.com/watch?v=PEgk2v6KntY</a>)<br><br>---<br><br>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.<span class="HOEnZb"><font color="#888888"><br><br>- Brian Gesiak</font></span></div></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>