-
Notifications
You must be signed in to change notification settings - Fork 24
Closed
Labels
ACP-acceptedAPI Change Proposal is accepted (seconded with no objections)API Change Proposal is accepted (seconded with no objections)T-libs-apiapi-change-proposalA proposal to add or alter unstable APIs in the standard librariesA proposal to add or alter unstable APIs in the standard libraries
Description
Proposal
Problem statement
I'd like a way to define lightweight custom I/O errors that don't require allocation.
Motivation, use-cases
- Offer a way forward for future better
#![no_std]compatibility forstd::io::Errors - Reduce generated code size for most common custom errors
- Avoid needing to allocate memory for the common case with custom errors.
For some prior art and additional motivation:
const_io_error!is already in broad use instd, with about 50 hits in a brief search: https://github.com/rust-lang/rust/search?q=const_io_error- https://sourcegraph.com/search?q=context:global+/%5CbError::new%5C%28%5Cs*%28%28std::%29%3Fio::%29%3FErrorKind::%5Cw%2B%5Cs*%2C%5Cs*%22/+count:all+timeout:10s&patternType=standard&case=yes&sm=0&groupBy=repo yielded 33.7k results across over 3.8k repos searching just for the conservative case-sensitive regexp
\bError::new\(\s*((std::)?io::)?ErrorKind::\w+\s*,\s*", with 14.2k results across 2.1k repos being of kindOther: https://sourcegraph.com/search?q=context:global+/%5CbError::new%5C%28%5Cs*%28%28std::%29%3Fio::%29%3FErrorKind::Other%5Cs*%2C%5Cs*%22/+count:all+timeout:10s&patternType=standard&case=yes&sm=0&groupBy=repo
Solution sketches
- Expose the internal
SimpleMessagestruct as a way to provide lightweight errors along with animpl From<&'static SimpleMessage> for Error. - Expose
const_io_error!to simplify construction ofSimpleMessage-based errors, and default its$kindtoErrorKind::Otherif not given.
Links and related work
std::error::Error->core::error::ErrorTracking Issue forErrorincorerust#103765 + Move Error trait into core rust#99917
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.
Metadata
Metadata
Assignees
Labels
ACP-acceptedAPI Change Proposal is accepted (seconded with no objections)API Change Proposal is accepted (seconded with no objections)T-libs-apiapi-change-proposalA proposal to add or alter unstable APIs in the standard librariesA proposal to add or alter unstable APIs in the standard libraries