Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

impl Default for ExitStatus #158

Closed
ijackson opened this issue Jan 4, 2023 · 1 comment
Closed

impl Default for ExitStatus #158

ijackson opened this issue Jan 4, 2023 · 1 comment
Labels
ACP-accepted API Change Proposal is accepted (seconded with no objections) api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api

Comments

@ijackson
Copy link

ijackson commented Jan 4, 2023

Proposal

Problem statement

It is not possible for code outside std to portably create an ExitStatus without actually running a process.

Motivation, use-cases

In some cases it might be convenient to use Option<ExitStatus>; but ExitStatus is already kind of option-ish in that it can represent an error, or no error.

It is IMO not reasonable to have a type that a user can mostly-portably create, but to require a user to run a dummy process to do so. This type can already be non-portably constructed on Unix and Windows via ExitStatusExt.

Solution sketches

The obvious-to-me answer is to impl Default for ExitStatus.

I did that in rust-lang/rust#106425 and am now belatedly making this ACP.

A consequence is that ExitStatus now becomes inhabited even on platforms without subprocesses. This seems reasonable.

Links and related work

See also the tracking issue for thec currently-unstable ExitStatusError, rust-lang/rust#84908. I'm postponing addressing the same question for ExitStatusError, but it should be considered before stabilisation.

What happens now?

This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.

@ijackson ijackson added api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api labels Jan 4, 2023
@m-ou-se
Copy link
Member

m-ou-se commented Jan 10, 2023

Thanks! This seems fine to me. I'll start the FCP on rust-lang/rust#106425.

(Perhaps we should also allow the creation of other statusses, maybe in the form of a From<ExitCode>. Although maybe ExitStatusExt::from_raw already suffices, at least on Windows and Unix platforms.)

@m-ou-se m-ou-se closed this as completed Jan 10, 2023
@dtolnay dtolnay added the ACP-accepted API Change Proposal is accepted (seconded with no objections) label Nov 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ACP-accepted API Change Proposal is accepted (seconded with no objections) api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api
Projects
None yet
Development

No branches or pull requests

3 participants