Add a simpler way to retrieve the exit status of a process

[Seldaek]

No description provided.

[huonw]

I think @alexcrichton suggested not having this when the new exit code handling was added, so that people don't ignore the possibility of failure-by-signal. (I'll defer to him about what he actually thinks though...)

[alexcrichton]

Yes, I was specifically avoiding having this method. You've currently got two options of saying status.matches_exit_status(n) or status == ProcessExit(n). I don't think that there's much benefit going from container to container when you can just match on the first value.

That being said, I haven't personally used the exit statuses that much, so have you found using the existing methods a pain? And if so, how come?

[Seldaek]

The use case is maybe not very common, but it is the one of forwarding the exit status. If I could just do std::os::set_exit_status(exit.exit_status().unwrap_or(1)) instead it would be cleaner and wouldn't require me to dive into which enum variants exist and whatnot.

[alexcrichton]

In that case, if you don't mind, I'm going to close this. I don't want to encourage unwrap behavior because the whole point of forcing exhaustive checks in enum matches is so that you're forced to think about the other possible cases. If it's easy to say status.unwrap() then it's very easy to lose information.

[Seldaek]

But you can't really just call unwrap can you? Or what happens if you call unwrap on None?

[alexcrichton]

That's the point is that you're not supposed to unwrap, by matching on the enum variant you're forced to look at all of the possible cases.

[Seldaek]

For posterity, the shortest alternative I found:

std::os::set_exit_status(match exit {
    std::io::process::ExitStatus(s) => s,
    _ => 1
});

Not sure if that's a best practice though readability-wise. Anyway I at least learned something doing this so it's not all lost.