Just thought I’d link the previous thread on this topic: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023927.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023927.html>. I had promised to write a proposal for it back then, but never got around to doing it. Now that we’re out of the hectic Swift 3 timeframe, I can write a proposal and implementation for this, since it’s more likely to be accepted.
More broadly, however, I think a “Swiftication” of POSIX or libc is extremely necessary for anyone who’s not working with Foundation–and not everyone is! There are still parts of POSIX that are either 1. not a part of Foundation or 2. part of Foundation/CoreFoundation but not in the open source Swift Foundation or CFLite (and hence not available on Linux). A big part of attracting newer Swift developers a moving away from the “Swift is for apps only” and the in my experience the need to drop down to UnsafePointer or errno just to use this API has been a big turn-off for programmers. Saagar Jha > On Aug 18, 2017, at 04:17, Xiaodi Wu via swift-evolution > <firstname.lastname@example.org> wrote: > > Not “fundamentally” incompatible: > > var stderr = FileHandle.standardError > /* Conform FileHandle to TextOutputStream */ > print("foo", to: &stderr) > > > On Fri, Aug 18, 2017 at 01:39 Brent Royal-Gordon <br...@architechies.com > <mailto:br...@architechies.com>> wrote: >> On Aug 17, 2017, at 8:20 PM, Xiaodi Wu via swift-evolution >> <email@example.com <mailto:firstname.lastname@example.org>> wrote: >> >> * stderr should go wherever stdin and stdout go. Since it’d be silly for a >> function like `print(_:separator:terminator:)` or >> `readLine(strippingNewline:)` to live anywhere but the standard library, >> then it stands to reason that the stderr version should also live in the >> standard library. >> >> FWIW, FileHandle.standardInput, FileHandle.standardError, >> FileHandle.standardOutput, and FileHandle.nullDevice all live in Foundation. > > And, since they're read-only, are fundamentally incompatible with > `print(…to:)`, which requires its `output` parameter to be passed `inout`. > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > email@example.com > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list firstname.lastname@example.org https://lists.swift.org/mailman/listinfo/swift-evolution