Tracking issue for RFC 1937: `?` in `main`

[aturon]

This is a tracking issue for the RFC "? in main" (rust-lang/rfcs#1937).

Steps:

• Implement the RFC (mentoring instructions can be found here).
  • ? in main (Implements RFC 1937: ? in main #46479)
  • ? in doctest
  • ? in #[test]
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Stabilizations:

• Stabilize main with non-() return types (Stabilize main with non-() return types #48453) Merged in Stabilize termination_trait, split out termination_trait_test #49162
• Stabilize unit tests with non-() return types (Stabilize unit tests with non-() return type #48854)

Related issues:

• Error message for unit tests is not great (error message when unit test type does not implement Termination is ungreat #50291)

Unresolved questions:

• The name of the trait being introduced
• The precise initial implementations
  • this will be stabilized by Stabilize main with non-() return types #48453
• exit codes (discussion) Moved to a separate tracking issue, Tracking issue for std::process::ExitCode (feature process_exitcode_placeholder) #48711
  • this will be stabilized by Stabilize main with non-() return types #48453 no longer true after Restrict the Termination impls to simplify stabilization #48497

How are exit statuses going to be dealt with?

[ketsuban]

This comment by @Screwtapello seems to have been made too close to the end of FCP for any alterations to be made to the RFC in response to it.

In short: the RFC proposes returning 2 on failure on grounds which, while well-founded, are obscure and produce a slightly unusual result; the least surprising thing is to return 1 when the program has no indication it wants any more detail than just success or failure. Is this sufficiently bikesheddy that it can be discussed without it feeling like we're perverting the RFC process, or are we now locked into this specific implementation detail?

It's not an implementation detail though, is it?

Some scripts use exit codes as a way to get information from a sub-process.

[Screwtapello]

This is specifically about the case when a sub-process (implemented in Rust) has no information to give, beyond a binary "everything's fine"/"something went wrong".

[NoraCodes]

Some scripts use exit codes as a way to get information from a sub-process.

That behavior is always extremely dependent on the program being called except in that non-zero means failure. Given that std::process::exit with a main-function wrapper and a lookup table is going to remain the best option for those who want a more articulate exit status no matter what is done, this seems like a mostly insignificant detail.

I don't think SemVer has a "mostly insignificant detail" exception though.

[glaebhoerl]

I think the exit code should be added to the unresolved questions list. @zackw also opened a related internals thread.

[liigo]

Many people agree that the exit code should be 1 on failure (instead of 2):
https://www.reddit.com/r/rust/comments/6nxg6t/the_rfc_using_in_main_just_got_merged/