Hi Dan,
Thank you for your proposal. This is the right place to start discussion of it.
If we want to do this then we would have to make changes in both Darwin and
open source versions, to maintain source compatibility.
Out of curiosity, why propose an enum instead of an additional set of typed
properties? Looking at the implementation of NSTask, it sure seems like we only
expect either a file handle or pipe. I’m not sure if we would ever add another.
- Tony
> On Dec 17, 2015, at 11:34 AM, Dan Stenmark via swift-corelibs-dev
> <swift-corelibs-dev@swift.org> wrote:
>
> This is my first proposal to swift-corelibs, so I’m not sure how much
> flexibility we have in terms of deviating from the darwin’s original
> Foundation definitions. That said, it’s always seemed a little screwy to me
> that NSTask's standardInput/standardOutput/standardError properties sacrifice
> any semblance of compile-time type safety by accepting id/AnyObject (which,
> at run time, must be either NSPipe or NSFileHandle, else it blows up). If
> allowed, I’d like to take the opportunity to modernize this in the open
> source version of Foundation.
>
> public class NSTask : NSObject {
>
> ...
>
> public enum IOType {
>
> case FileHandle(NSFileHandle)
> case Pipe(NSPipe)
> }
>
> public var standardInput: NSTask.IOType?
> public var standardOutput: NSTask.IOType?
> public var standardError: NSTask.IOType?
>
> ...
>
>
> }
>
> Dan
>
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
