<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 5, 2016, at 10:29 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Oct 5, 2016, at 3:57 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">I hadn't thought about a unified overlay for POSIX. I think the simplified import alone has benefit to warrant its own evolution proposal. Would it be possible to have a separate discussion for the POSIX overlay idea? Or is there a reason that I'm missing that prevents the import from being viable on its own? (Apologies in advance if there's an obvious answer to this question!)<br class=""></blockquote><br class="">I've heard the argument before that we should do a full overlay, but I think this is becoming a case of the perfect being the enemy of the good. Having some sort of "just import whatever the system libc is called" module would be a significant improvement in practice over the state of the art, even if we don't do any other adaptation.<br class=""></blockquote><br class="">I’ve come around to agree with this position. I think it makes sense to have a cross platform “libc” which is an alias for darwin, glibc, or whatever, and just leave it at that.<br class=""><br class="">Other proposals for a “POSIX” module have gotten bogged down because inevitably the idea comes up to make the resultant API nicer in various ways: rename creat, handle errno more nicely, make use of multiple return values, … etc. The problem with this approach is that we don’t *want* people using these layer of APIs, we want higher level Foundation-like APIs to be used.<br class=""><br class="">That’s why I think the best way to split the difference is to do as you suggest. This allows the implementation of Foundation (and similar level of APIs) to be nicer, but not get bogged down trying to figure out how to clean up POSIX.<br class=""><br class=""><blockquote type="cite" class="">Here's what I would suggest. We have a convention for exposing "raw" imports of C libraries: you call them `C\(libraryName)`. So I would suggest we introduce a `CLibc` module which provides a raw import of the system's libc. If we later decide to do a full-featured overlay, that's great—we can call it `Libc`. But `CLibc` by itself would be an improvement over the status quo and a step in the right direction.<br class=""></blockquote><br class="">I think we should formally decide that a “nice” wrapper for libc is a non-goal. There is too much that doesn’t make sense to wrap at this level - the only Swift code that should be using this is the implementation of higher level API, and such extremely narrow cases that we can live with them having to handle the problems of dealing with the raw APIs directly.<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>I don’t know, I kind of take issue with the last point there. I don’t think it’s a foregone conclusion that applications and frameworks aren’t going to need to be using these APIs. As I understand it’s not the goal of Foundation to provide all of the functionality of POSIX. And I know of at least 5 serverside and/or networking libraries which each provide their own abstractions over the POSIX interface. Unfortunately I think that breed incompatibility that bubbles up from underneath. </div><div><br class=""></div><div>For example, each library is going to have to redefine their own concepts of a “SystemError” for example (a la <a href="https://github.com/Zewo/POSIX/blob/master/Sources/POSIX/SystemError.swift" class="">this</a> and <a href="https://github.com/PerfectlySoft/Perfect/blob/master/Sources/PerfectLib/PerfectError.swift#L37" class="">this</a> and <a href="https://github.com/vapor/engine/blob/master/Sources/HTTP/Server/ServerError.swift#L3" class="">this</a>, etc). If I want to use two of these libraries now I’ve got conflicting versions of “SystemError”s. What I’m saying is that realistically as system error is a system error and having six different ways to wrap it is not only unfortunate for the library developers, but confusing for the users of the library.</div><div><br class=""></div><div>I certainly hear the argument that these should be wrapped in higher level concepts (even perhaps system errors, although there’s only so much wrapping to be done here), but I think we should do some more investigation into whether the cases are actually that narrow. I just want to avoid 10 slightly different thin wrappers around POSIX which are confusing to users of libraries. And each of these wrappers have the same potential for subtle POSIX errors.</div><div><br class=""></div><div>Perhaps the way to do it is to make more targeted which are auxiliary to Foundation, like “Networking” or “IO” or “Files” (even though there is overlap here, e.g. system errors as above). The intention here would be not to rearchitect POSIX, but to define base levels of functionality reduce or eliminate the need to make POSIX calls. Or perhaps just widen the reach of Foundation to provide that base functionality.</div><div><br class=""></div><div>For example, would a TCPSocket class belong in Foundation? It’s already got HTTPCookies.</div><div><br class=""></div><div>Tyler</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">-Chris<br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>