On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift <kelvin1...@gmail.com> wrote:
> I don’t think the “is this library functionality or standard library > functionality” argument is worth having, but if stdout and stdin are > first-class citizens in the Swift world, so should stderr. > > As for bringing Foundation into the discussion, you can’t really talk > about Foundation without also talking about the mountains of problems that > come with the monolith pattern. But that’s a completely different > conversation to be had. > I'm not sure what you're getting at here, but I don't believe you've addressed my question, which is: it's been firmly decided that I/O belongs in Foundation, and Foundation does in fact offer such facilities--what is missing from those facilities, and how can we fill it out? On Thu, Aug 17, 2017 at 7:13 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> IMO, you’re touching on at least three or four separate topics here. >> Daniel touched on several, but just some comments/questions: >> >> * Standard error output is something that’s been discussed here >> previously. I believe the last pitch had something like StandardError being >> added to the standard library as a TextOutputStream. >> >> * Foundation is supposed to be the core library that provides file system >> access facilities. What’s missing, and can we add it to Foundation? >> >> On Thu, Aug 17, 2017 at 17:50 Taylor Swift via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> Python’s os.path <https://docs.python.org/2/library/os.path.html> is a >>> nice abstract model for doing path manipulations. Maybe Swift could get a >>> struct like `Filepath` or something on which these operations could be done. >>> >>> On Thu, Aug 17, 2017 at 6:47 PM, Taylor Swift <kelvin1...@gmail.com> >>> wrote: >>> >>>> >>>> >>>> On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar <daniel_dun...@apple.com >>>> > wrote: >>>> >>>>> >>>>> > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution < >>>>> swift-evolution@swift.org> wrote: >>>>> > >>>>> > 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. >>>>> >>>>> What we (SwiftPM) have done for now is use a `libc` target to start by >>>>> normalizing the name: >>>>> https://github.com/apple/swift-package-manager/tree/master/ >>>>> Sources/libc >>>>> (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). >>>>> >>>>> 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: >>>>> https://github.com/apple/swift-package-manager/tree/master/ >>>>> Sources/POSIX >>>>> https://github.com/apple/swift-package-manager/tree/master/ >>>>> Sources/Basic >>>>> >>>>> 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. >>>>> >>>>> > 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. >>>>> >>>>> 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? >>>>> >>>> >>>> I don’t know if it’s actually this simple, but could it just be the >>>> symbols that are defined in both modules? >>>> >>>> >>>>> >>>>> > 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. >>>>> >>>>> 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). >>>>> >>>>> 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? >>>>> >>>>> +1 in general agreement with the meta-issue being an important one to >>>>> discuss. >>>>> >>>> >>>> There probably is an XY issue at play here; what we *really* 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. >>>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution