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

Open
#747 5 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
rust
Domain
embedded-iot

Research direction

Start by reviewing the proposed alloc::io and core::io implementations and the existing embedded-io, embedded-io-adapters, and embedded-io-async crates. Compare the proposal's MSRV, alloc, error-type, blocking, and async implications with the linked futures-io work. Done means establishing a maintainer-backed direction for replacement, augmentation, or continued use; no implementation files or tests are named.

Written by the indexing model from the issue text.

Description

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 #694, #686, and #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.
Dominant language
Rust
Stars
2.7k
Forks
282
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rust-embedded/embedded-hal

All issues in rust-embedded/embedded-hal

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.