Tracking Issue for ExitCode::exit_process()

[coolreader18]

Feature gate: #![feature(exitcode_exit_method)]

This is a tracking issue for the ExitCode::exit_process() method.

exit_code.exit_process() exits the process with the ExitCode passed as the self argument.

Public API

impl std::process::ExitCode {
    pub fn exit_process(self) -> !;
}

Steps / History

• Implementation: ExitCode::exit_process() method #95356
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Name of the method? Might be better to have a free function instead of associated method, but then there's no good name for it that wouldn't overlap with the existing process::exit. As a postfix verb it's sorta clunky, or maybe doesn't communicate explicitly with what the process is being exited? I think exit_process strikes a good balance but I discussed it more in the impl PR ExitCode::exit_process() method #95356.

Thoughts on naming it something like exit_with?

ExitCode::SUCCESS.exit_with()
// vs
ExitCode::SUCCESS.exit_process()

let code = ExitCode::FAILURE;
code.exit_with()
// vs
code.exit_process()

[ChrisDenton]

In the standard library, the _with suffix is generally used in functions that take a closure (the exception starts_with and ends_with that take a slice or pattern).

[coolreader18]

(and {starts,ends}_with can take a closure if you really want to, Fn(char) -> bool impls Pattern 🙃 )

But yeah, I was thinking about that @h4x5 but the "word order" didn't really make sense, and also the closure thing.

[bjoernager]

My first thought was naming this consume but I don't know how obvious the intentions of that name would be for others.

[ChrisDenton]

I would like to propose stabilising this. Currently there is no way to use ExitCode in process::exit, which is a pain when you want to support both returning from main and process:exit.

Alternatively (or even additionally) there could be a method on ExitCode that converts it to an i32 that can be passed to process::exit.

[Bee4Queer]

For the latter point, it looks like there's a #[doc(hidden)], perma-unstable function called to_i32 on ExitCode. I may not be a member of any rust teams, but I second the point to propose stabilizing this.