> On Oct 5, 2016, at 10:29 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: > > On Oct 5, 2016, at 3:57 PM, Brent Royal-Gordon <[email protected]> wrote: >>> On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution >>> <[email protected]> wrote: >>> 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!) >> >> 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. > > 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. > > 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. > > 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. > >> 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. > > 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. >
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. For example, each library is going to have to redefine their own concepts of a “SystemError” for example (a la this <https://github.com/Zewo/POSIX/blob/master/Sources/POSIX/SystemError.swift> and this <https://github.com/PerfectlySoft/Perfect/blob/master/Sources/PerfectLib/PerfectError.swift#L37> and this <https://github.com/vapor/engine/blob/master/Sources/HTTP/Server/ServerError.swift#L3>, 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. 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. 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. For example, would a TCPSocket class belong in Foundation? It’s already got HTTPCookies. Tyler > -Chris > > > _______________________________________________ > 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
