<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 17, 2017, at 3:47 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="gmail_extra" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline"><br class=""><div class="gmail_quote">On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:daniel_dunbar@apple.com" target="_blank" class="">daniel_dunbar@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><span class=""><br class="">> On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">><br class="">> I know this has come up before without any action, but having the standard C library be packaged under `Darwin` on OSX and `Glibc` under Linux is something that’s really becoming an issue as the Swift package ecosystem matures. Right now a lot of packages are a lot less portable than they could be because somewhere along the dependency line, there is a package that only imports the C library for one platform. Unifying it under one import would allow people to write packages that are portable by default.<br class=""><br class=""></span>What we (SwiftPM) have done for now is use a `libc` target to start by normalizing the name:<br class=""> <span class="Apple-converted-space"> </span><a href="https://github.com/apple/swift-package-manager/tree/master/Sources/libc" rel="noreferrer" target="_blank" class="">https://github.com/apple/<wbr class="">swift-package-manager/tree/<wbr class="">master/Sources/libc</a><br class="">(and in the past, when we find missing things in Glibc getting them added to the compiler). Also, this name is technically a misnomer, but we couldn’t think of a better one (“os” might have been a good one).<br class=""><br class="">Unfortunately, I think this change alone is really only the tip of the iceberg. It would be nice to not have it the difference, but we found we very quickly needed several other layers on top to get to having a relatively stable cross-platform base:<br class=""> <span class="Apple-converted-space"> </span><a href="https://github.com/apple/swift-package-manager/tree/master/Sources/POSIX" rel="noreferrer" target="_blank" class="">https://github.com/apple/<wbr class="">swift-package-manager/tree/<wbr class="">master/Sources/POSIX</a><br class=""> <span class="Apple-converted-space"> </span><a href="https://github.com/apple/swift-package-manager/tree/master/Sources/Basic" rel="noreferrer" target="_blank" class="">https://github.com/apple/<wbr class="">swift-package-manager/tree/<wbr class="">master/Sources/Basic</a><br class=""><br class="">My hope is that one minimal improvement we can get soon is multi-package repo support in SwiftPM, which will at least allow us to share those targets & functionality with other packages.<br class=""><span class=""><br class="">> Since I think this got hung up in the past over “what constitutes” a universal libc, I propose a unified package should just consist of the functionality that is common between Darwin and Glibc right now, since those are the only two supported platforms anyway.<br class=""><br class=""></span>What would the concrete proposal be? It isn’t trivial to determine that subset and make it well-defined what the exact API is. Is the proposal to just to pick a standard name, and reexport Darwin and Glibc from it?<br class=""></blockquote><div class=""><br class=""></div><div class="">I don’t know if it’s actually this simple, but could it just be the symbols that are defined in both modules?<br class=""></div></div></div></div></blockquote><div><br class=""></div>I think this would be hard to implement in practice. There are also symbols which are defined the same, but behave differently (or accept slightly different types). Reconciling all of that would be a large project.</div><div><br class=""><blockquote type="cite" class=""><div class="gmail_extra" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><span class="">> Alternatively, Swift could make it a priority to get basic functionality like file IO and math functions shipped with the compiler, which would probably cover 98% of cases where people currently import Darwin/Glibc. A large portion of the standard C libraries are redundant to the Swift standard library anyway.<br class=""><br class=""></span>I’m not sure I agree with these statements about the percentages. For some clients (I’m biased, the areas I work in tend to be in this boat), what we largely need is good platform-agnostic access to the POSIX APIs. This is a hard problem to make a good cross-platform API for (esp. if Windows support is in your head), and which many projects struggle with (Netscape :: NSPR, LLVM :: libSupport, many many more).<br class=""><br class="">The sticking point I see is this: if the proposal is just to unify the name & that doesn’t actually buy us all that much (still need standard layers on top), then have we really solved enough of a problem to be worth standardizing on?<br class=""><br class="">+1 in general agreement with the meta-issue being an important one to discuss.<br class=""></blockquote></div><br class=""></div><div class="gmail_extra" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">There probably is an XY issue at play here; what we<span class="Apple-converted-space"> </span><i class="">really</i><span class="Apple-converted-space"> </span>need is a way to access the file system built into the standard library. (Math functions are a separate, beleaguered topic for a different thread.) Having support for outputting to `stderr` is also something I’d really like. Going through Glibc/Darwin is just one way to solve this.</div></blockquote></div><br class=""><div class="">Right, this is exactly the kind of thing SwiftPM’s Basic has.</div><div class=""><br class=""></div><div class=""> - Daniel</div><div class=""><br class=""></div></body></html>