In that case I think the discussion is kind of moot, scripts are fundamentally different than apps, being terse is important and almost always you want to block.
If better scripting support is a non-goal for Foundation then `Process` is mostly fine as it is. My only wish would be to somehow make it easier to read and write `Data` to stdin/stdout/stderr. On Tue, Nov 28, 2017 at 11:30 PM, Tony Parker <anthony.par...@apple.com> wrote: > Of course, Foundation API has no way of distinguishing if the caller is > considered a script or not. > > If the API is a bad idea for other kinds of apps then we simply wouldn’t > add it. So, I think this proposed convenience API needs to consider all of > the varied clients of Foundation. > > - Tony > > > On Nov 28, 2017, at 12:24 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > > On Nov 28, 2017, at 8:00 AM, Tony Parker <anthony.par...@apple.com> wrote: > > Why does it imply a run loop rather than one of many multithreading > possibilities (dispatch queue, starting one more thread, etc)? And even if > it did use run loops, why is that a problem? > > > The problem is simply that we're discussing using this feature in Swift > *scripts*. Swift scripts don't typically invoke `RunLoop.run()` or > `dispatch_main()`, and without changing the way they generate main() > functions to intrinsically do so (and then schedule main.swift's body on > the main runloop/queue), I don't see a good way for it to do so. So an > async API would be inconvenient to use from a Swift script. > > -- > Brent Royal-Gordon > Architechies > > >
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
