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

Expose the internal SimpleMessage struct and allow creating std::io::Errors with them #205

Closed
dead-claudia opened this issue Apr 7, 2023 · 2 comments
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

@dead-claudia
Copy link

Proposal

Problem statement

I'd like a way to define lightweight custom I/O errors that don't require allocation.

Motivation, use-cases

  1. Offer a way forward for future better #![no_std] compatibility for std::io::Errors
  2. Reduce generated code size for most common custom errors
  3. Avoid needing to allocate memory for the common case with custom errors.

For some prior art and additional motivation:

Solution sketches

  1. Expose the internal SimpleMessage struct as a way to provide lightweight errors along with an impl From<&'static SimpleMessage> for Error.
  2. Expose const_io_error! to simplify construction of SimpleMessage-based errors, and default its $kind to ErrorKind::Other if not given.

Links and related work

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.

@dead-claudia dead-claudia added api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api labels Apr 7, 2023
@joshtriplett
Copy link
Member

We discussed this in today's @rust-lang/libs-api meeting. We were in favor of adding the macro for this, and not stabilizing SimpleMessage (since the macro can use internal unstable). We'd like to call the macro std::io::const_error!, so that people who already have use std::io can conveniently use io::const_error!(...).

@joshtriplett joshtriplett added the ACP-accepted API Change Proposal is accepted (seconded with no objections) label Oct 1, 2024
@dead-claudia
Copy link
Author

@joshtriplett Is there a tracking issue or PR I can follow?

joboet added a commit to joboet/rust that referenced this issue Nov 25, 2024
joboet added a commit to joboet/rust that referenced this issue Nov 25, 2024
jhpratt added a commit to jhpratt/rust that referenced this issue Nov 26, 2024
std: expose `const_io_error!` as `const_error!`

ACP: rust-lang/libs-team#205
Tracking issue: rust-lang#133448

Probably best reviewed commit-by-commit, the first one does the API change, the second does the mass-rename.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Nov 27, 2024
std: expose `const_io_error!` as `const_error!`

ACP: rust-lang/libs-team#205
Tracking issue: rust-lang#133448

Probably best reviewed commit-by-commit, the first one does the API change, the second does the mass-rename.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Nov 27, 2024
Rollup merge of rust-lang#133449 - joboet:io_const_error, r=tgross35

std: expose `const_io_error!` as `const_error!`

ACP: rust-lang/libs-team#205
Tracking issue: rust-lang#133448

Probably best reviewed commit-by-commit, the first one does the API change, the second does the mass-rename.
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

2 participants