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 
> <swift-evolution@swift.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 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.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
> 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

Reply via email to