Consider Replacing/Augmenting `embedded-io(-*)` with `alloc::io` and `futures-io`

[bushrat011899]

Background

With rust-lang/rust#154046 implemented, nightly now has a full implementation of std::io available from alloc::io, and a partial implementation available from core::io. With that, other crates such as futures-io can gain no_std support, potentially making them viable in the embedded space.

Proposal

• Increase MSRV to whatever version contains a stabilized alloc::io & core::io.
• Directly use core::io and (where required) alloc::io for synchronous I/O.
• Use futures-io for asynchronous I/O.
• Deprecate embedded-io, embedded-io-adapters, and embedded-io-async.

Drawbacks

• Read and BufRead are currently only available from alloc::io. embedded-io provides alternatives to those traits even without the alloc feature enabled, so using the standard library I/O traits would increase the need for downstream crates to enable the alloc feature.
• embedded-io allows changing the error type used for I/O operations, whereas the standard library traits use core::io::Error exclusively.
• embedded-io guarantees its trait implementations are blocking, deferring non-blocking support to ReadReady and WriteReady. These traits could remain, or embedded-hal could move towards the standard library approach of mixed non-/blocking.

Benefits

• Three fewer crates to maintain.
• Standardised I/O interface which would allow non-embedded crates to more easily be used in an embedded context (e.g., flate2)
• Potentially reduced friction for users starting in embedded Rust by avoiding divergence (as noted in io: undocumented behavioral divergence between std::io and embedded-io. #694, io: Missing methods on the Seek and BufRead trait #686, and Expand embedded_io::ErrorKind to better match std::io::ErrorKind. #648)

---

Notes

• I'm one of the contributors working on alloc_io and core_io. I'm opening this issue to gauge interest in a standard library implementation of no_std I/O, and whether it may be suitable for stabilization.

[mkj]

It looks like it wouldn't be hard for futures-io to drop its std feature and always be no-alloc once core::io::Error stabilises. That could replace embedded-io-async I think?

embedded-io is harder since a lot of embedded cases are no-alloc. Is there a path to moving alloc:io::Read to core?

[bushrat011899]

It looks like it wouldn't be hard for futures-io to drop its std feature and always be no-alloc once core::io::Error stabilises. That could replace embedded-io-async I think?

That is correct! Only need alloc for implementing its traits for alloc types.

embedded-io is harder since a lot of embedded cases are no-alloc. Is there a path to moving alloc:io::Read to core?

There is a rough plan to add a form of supertrait auto-implementation so Read could be split into two traits (one in core and one in alloc), but that's much further away from stabilisation (IMO). Even without replacing Read in embedded-io, Write, SeekFrom, Seek, ErrorKind, etc. could all be replaced with their core::io counterparts. It's not ideal, but maybe embedded platforms could add a stub allocator just to link the alloc crate? The Read and BufRead traits only allocate when you explicitly call methods like Read::read_to_end.

Another alternative is that alloc::io is compatible with no_global_oom_handling. Users would need to compile alloc with that flag set, but it would ensure any allocation failures are returned as I/O errors.

[carloskiki]

One thing my project relies on (and I assume others also do) is specifying the associated Error type. I assume core can't add the associated type because it would be breaking (perhaps with associated type defaults it would be possible?). So a migration of ErrorKind would be nice, but I don't know if I am in favour of also migrating Read, Write and Seek.

[bushrat011899]

One thing my project relies on (and I assume others also do) is specifying the associated Error type. I assume core can't add the associated type because it would be breaking (perhaps with associated type defaults it would be possible?).

Correct regarding why core has a fixed error type. Out of curiosity, do you need a custom type because you need to convey infallibility, or additional information about your I/O failure, or some other reason? Would be helpful to understand for the stabilization discussion!

So a migration of ErrorKind would be nice, but I don't know if I am in favour of also migrating Read, Write and Seek.

That's what I was thinking as a mild improvement even if the current traits couldn't really be replaced.

[carloskiki]

Yes, my current use case is almost exclusively for type Error = Infallible. I also have Error set to other types (most of these are subsets of io::Error that only contain the possibly returned kinds), but these would easily be migrated into core::io::Error::new(). Even then, infallible error types are just a nice QoL thing, nothing I’d be too disappointed to lose.