Stabilize `main` with non-() return types

[nikomatsakis]

This is a sub-issue of the larger tracking issue devoted to the ? in main RFC. It is specifically proposing that we stabilize the behavior that permits main to have a return type other than (). This return type must implement the Termination trait. The details of the trait itself (including its name and so forth) are not stabilized.

This commits us to the following (each link is to a test):

• fn main() -> i32
  • return value is the exit code of the process
• fn main() -> ! (no test, but here is the impl -- a test is being added in Termination trait in tests #48143)
  • should never return
• fn main() -> Result<(), E> where E: Debug
  • on Err, a Debug printout occurs
  • these impls are modified in Restrict the Termination impls to simplify stabilization #48497
• fn main() -> Result<!, E> where E: Debug
  • these impls are modified in Restrict the Termination impls to simplify stabilization #48497

The changes from the RFC are as follows:

• we modified the Result impl to use Debug

The following unresolved questions will be resolved:

• The precise initial implementations
  • as above
• exit codes (discussion)
  • these are defined as libc::EXIT_SUCCESS for "Ok" and libc::EXIT_FAILURE for "Err"
  • except for wasm, where they are currently defined as 0 or 1 for wasm -- this is because those constants are/were not available for wasm
  • (they also appear not to be publicly exported? but that is not part of this stabilization)

But the following is not stabilized and free to change:

• the name/location of the Termination trait and its methods
  • likely changing to std::process::Termination
• the usage of -> Result<...> in unit tests (not yet landed)
• the ErrCode newtype wrapper for returning a custom error code

--

UPDATE 1: Restricted the set of termination impls as proposed by @scottmcm in #48497.

[nikomatsakis]

@rfcbot fcp merge

I propose that we stabilize as described above.

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

• @aturon
• @cramertj
• @eddyb
• @nikomatsakis
• @nrc
• @pnkfelix
• @withoutboats

Concerns:

• delay stabilization of nesting and i32 exit code resolved by Stabilize main with non-() return types #48453 (comment)

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[scottmcm]

👍 to stabilizing the basics here.

👎 to some of the allowed return types.

I would propose only stabilizing the following new return types:

• !
• Result<(), E: Debug>
• Result<!, E: Debug>

Thoughts on the others:

• Arbitrary nesting is weird. Why would one have a Result<Result<!, io::Error>, fmt::Error>?
• Nesting also makes return values weird, like with Result<i32, _> you run into collisions with Ok(1) and Err(_).
• I still prefer some domain-specific type (strawman ExitCode) to i32. I could accept just fn main() -> i32, but it feels like primitive obsession (especially if nesting happens, where it's meaning is far less clear). There were some interesting discussions in the RFC about platform differences here too, which feel like they could be a good fit with the "vision for portability" stuff. And this case in particular isn't needed for the ?-in-main goals, so can easily wait. As a bonus, I think having a type here that's not a primitive would let us leave the impl but have have the type unstable as the details are figured out.

I'll happily make a PR restricting things as above if that'd be helpful.

[cramertj]

@rfcbot concern delay stabilization of nesting and i32 exit code

I feel basically the same way that @scottmcm does-- nesting (e.g. Result<i32, Error>) seems confusing and hard to reason about, and i32 seems like it should be ExitCode, perhaps with a from_raw method. Can we delay stabilizing these particular impls pending further discussion? I'd love to see ! and Result<!/(), E: Debug> stabilize.

Edit: also bool?

[bkchr]

Yeah it is the opposite, wasm is 0 and 1 and all other platforms use libc::*. I have done that, because libc::EXIT_SUCCESS and libc::EXIT_FAILURE were not available at that time for wasm in libc.

[scottmcm]

I noticed that there's impl Termination for bool right now too (it's not mentioned in the OP), which I don't think should be part of the minimal set that we stabilize in the first pass.

[ExpHP]

The RFC says E: Display instead of E: Debug, and tbh, Display would have been my first choice as well. But I'm sure this has been discussed.

Should the RFC be amended to reflect this change, and to explain why Debug is the right choice?

[U007D]

@ExpHP yes, you are correct. Something approaching a summary of thinking around Display vs Debug starts around here: #43301 (comment).

[withoutboats]

I'm surprised by the concern about nesting - how would someone come to nest results in their main return anyway? It seems like the natural way to implement termination, which has the consequence of enabling this kind of thing, but that it happening in practice would be a non-issue.

Should RFC be amended to reflect this change, and to explain why Debug is the right choice?

we do not usually amend RFCs to cover changes before stabilization. they are design documents for implementation, they dont play any sort of 'constitutional' role.

[U007D]

@withoutboats, that is interesting.

If I'm understanding you correctly, by allowing Result<T, E>, T itself may be a Result<U, F>, but that we should not invent extra machinery to disallow this? That does make a lot of sense...

Personally, I was only considering what to allow from the perspective of being conservative; but when being conservative mandates extra logic to specifically disallow certain types, I can see the problem. (Such a limitation could also feel quite arbitrary in blocking some scenario we might not be imagining at the moment...)

Thanks, as usual, for the enlightening perspective. :)

[nikomatsakis]

Fixed the wasm reference.

I also thought we might want to limit the impls. Note that we have no mechanism for "feature-gating" impls, so the only way to limit things once we stabilize the basic concept is to remove the stuff we don't want.

I think that supporting only the basics (!, (), and Result<(), E>) seems good to start -- I anticipate that anyone who wants to use this feature for more complex things will define their own new-type and implement Terminate themselves. That is certainly what I plan to do in my own code, since I think it's a nice way to separate out the error handling from the rest.

If we wanted to go crazy (I don't), I could imagine adding a new trait like SuccessfulTerminate and then implementing Terminate for T and Result<T, E> where T: SuccessfulTerminate. This avoids nesting but keeps flexibility. (We would implement SuccessfulTerminate for () and ExitCode or something.) But it feels like overkill, and it can be readily modeled with your own newtype anyhow.