Jack O'Connor 2a345bbcc1 make Child::try_wait return io::Result<Option<ExitStatus>> ... This is much nicer for callers who want to short-circuit real I/O errors with `?`, because they can write this if let Some(status) = foo.try_wait()? { ... } else { ... } instead of this match foo.try_wait() { Ok(status) => { ... } Err(err) if err.kind() == io::ErrorKind::WouldBlock => { ... } Err(err) => return Err(err), } The original design of `try_wait` was patterned after the `Read` and `Write` traits, which support both blocking and non-blocking implementations in a single API. But since `try_wait` is never blocking, it makes sense to optimize for the non-blocking case. Tracking issue: https://github.com/rust-lang/rust/issues/38903		2017-02-06 23:04:47 -05:00
..
redox	make Child::try_wait return io::Result<Option<ExitStatus>>	2017-02-06 23:04:47 -05:00
unix	make Child::try_wait return io::Result<Option<ExitStatus>>	2017-02-06 23:04:47 -05:00
windows	make Child::try_wait return io::Result<Option<ExitStatus>>	2017-02-06 23:04:47 -05:00
mod.rs	Fix compile errors and such	2016-12-20 14:09:50 -08:00