Skip to content

impl Default for ExitStatus #158

New issue

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

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

Already on GitHub? # to your account

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
# for free to join this conversation on GitHub. Already have an account? # 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