Why limit the use of `std::io::const_io_error!` inside std?

It could be useful to create std::io::Error outside std without allocate.

It both allocates and depends on the Error trait which isn't yet stably in core. And is also primarily used for other things that live in std (there is no core::io).

3 Likes

I'd also add that public items have a stability guarantee. The standard library, like any library, has freedom to mess about with its internal things but, unlike other libraries, once something is stabilized it's stabilized forever. Is const_io_error! really the best interface? It's changed before and could change again... unless it's stabilized then we're stuck with it.

Putting APIs like Read, Write, Seek, Error in core without the OS-specific parts may be useful. But there are some problems: for example, IoSlice is OS-specific, and it is included in the Write API.

FWIW, the stable alternative is <Error as From<io::ErrorKind>>::from. It's not const-compatible, but accomplishes a similar goal of creating an io::Error with a kind but no payload. This does mean, however, that it can't have any message beyond just the kind.

Intended for use for errors not exposed to the user, where allocating onto the heap (for normal construction via Error::new) is too costly.

Error::from_raw_os_error is also somewhat relevant; both APIs are most useful when dealing with FFI that gives you the kind of failure but no more context.

Small clarification: it doesn't do any runtime allocation. What it does do is static promotion, which is meaningfully different.

Also somewhat relevant to why it's not exposed is that exporting it would rely on either unstable macro "2.0" hygiene and/or exposing even more API surface (i.e. io::Error::from_static_message) in order to be implemented.

It's not unreasonable that std would expose such functionality, but it hasn't yet been deemed worth the complexity of committing to such always being possible in perpetuity. IO errors are generally outside of the critical path anyway, and especially ones generated outside std with more context than an OS error.

I believe OP was asking about "outside std" as in 3rd party libraries and "without allocate" as in without performing any runtime allocation, not as in with just core and without the alloc or std crates available.

Yeah, I misread the original question (as if the OP body existed, but the title did not).

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.