Skip to content

Tracking Issue for alloc::io and core::io #154046

Open
Open
Tracking Issue for alloc::io and core::io#154046
Labels
C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCS-tracking-unimplementedStatus: The feature has not been implemented.T-libsRelevant to the library team, which will review and decide on the PR/issue.

Description

@a1phyr
a1phyr
opened on Mar 18, 2026

View all comments

Feature gate: #![feature(alloc_io)]

This is a tracking issue for using module io in alloc (and hopefully in core one day).

Public API

alloc::io and core::io modules.

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

Unresolved Questions

  • None yet.

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

Activity

  1. a1phyr
    added
    T-libs-api[DEPRECATED; DO NOT USE]
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    S-tracking-unimplementedStatus: The feature has not been implemented.
    on Mar 18, 2026
  2. a1phyr
    changed the title [-]Tracking Issue for `alloc::io`[/-] [+]Tracking Issue for `alloc::io` and `core::io`[/+] on Mar 19, 2026
  3. bushrat011899
    added a commit that references this issue on Apr 1, 2026

    Move `std::io::ErrorKind` to `core::io::ErrorKind`

    6acf3fc
  4. Mark-Simulacrum
    added
    I-libs-api-nominated[DEPRECATED; DO NOT USE]
    on Apr 11, 2026

  5. Mark-Simulacrum commented on Apr 11, 2026

    @Mark-Simulacrum
    Mark-Simulacrum
    on Apr 11, 2026
    Member

    In #154654, we noted that core::io is currently gated with the feature gate core_io_borrowed_buf (code).

    I would like to propose we stabilize core::io and alloc::io existing while leaving the contents unstable for now. That would avoid users needing to add multiple feature gates, and I think it's highly likely those names will remain in existence (and eventually have contents). Can libs-api approve that, either via FCP or just commenting here (since we're just stabilizing the modules not convinced a 10+ day wait is really needed).

  6. Amanieu commented on Apr 14, 2026

    @Amanieu
    Amanieu
    on Apr 14, 2026
    Member

    We discussed this in the @rust-lang/libs-api meeting. We're not inclined to stabilize these modules before at least one item is stabilized inside them.

    If excessive feature gates are a concern, this could be simplified by just having a single core_io feature that covers anything in core::io that is already stable today.

  7. Amanieu
    removed
    I-libs-api-nominated[DEPRECATED; DO NOT USE]
    on Apr 14, 2026
  8. jhpratt
    added 2 commits that reference this issue on Apr 19, 2026

    Rollup merge of rust-lang#154654 - bushrat011899:core_io_error_kind, …

    877c205

    Rollup merge of rust-lang#154654 - bushrat011899:core_io_error_kind, …

    e77f9ae
  9. JonathanBrouwer
    added a commit that references this issue on Apr 20, 2026

    Rollup merge of rust-lang#154654 - bushrat011899:core_io_error_kind, …

    3ca43dc
  10. rust-timer
    added a commit that references this issue on Apr 20, 2026

    Unrolled build for #154654

    3f77a8f

  11. bushrat011899 commented on Apr 23, 2026

    @bushrat011899
    bushrat011899
    on Apr 23, 2026 · Hidden as resolved
  12. jhpratt
    added a commit that references this issue on Apr 24, 2026

    Rollup merge of rust-lang#155684 - bushrat011899:blanket_io_seek_for_…

    e002c6c

  13. 111 remaining items

  14. nia-e commented on Aug 11, 2026

    @nia-e
    nia-e
    on Aug 11, 2026
    Member

    Per today's libs meeting, we'd be happy to start FCP on a stabilisation PR for the above ^^ @bushrat011899 feel free to open one & ping us there

  15. programmerjake commented on Aug 11, 2026

    @programmerjake
    programmerjake
    on Aug 11, 2026
    Member

    Per today's libs meeting, we'd be happy to start FCP on a stabilisation PR for the above ^^ @bushrat011899 feel free to open one & ping us there

    I'm assuming by "above ^^" you mean #154046 (comment)?

  16. bushrat011899 commented on Aug 11, 2026

    @bushrat011899
    bushrat011899
    on Aug 11, 2026
    Contributor

    Per today's libs meeting, we'd be happy to start FCP on a stabilisation PR for the above ^^ @bushrat011899 feel free to open one & ping us there

    Excellent, will open one shortly!

    I'm assuming by "above ^^" you mean #154046 (comment)?

    That's how I interpret it as well, especially reading the meeting notes.

  17. nia-e commented on Aug 11, 2026

    @nia-e
    nia-e
    on Aug 11, 2026
    Member

    yep, that's correct

  18. JonathanBrouwer
    added 2 commits that reference this issue on Aug 12, 2026

    Rollup merge of rust-lang#160952 - bushrat011899:write_for_cursor_sta…

    91f6d37

    Rollup merge of rust-lang#160952 - bushrat011899:write_for_cursor_sta…

    02d9b63
  19. rust-timer
    added a commit that references this issue on Aug 12, 2026

    Unrolled build for #160952

    4bd7116
  20. clarfonthey
    added
    T-libsRelevant to the library team, which will review and decide on the PR/issue.
    and removed
    I-libs-api-nominated[DEPRECATED; DO NOT USE]
    T-libs-api[DEPRECATED; DO NOT USE]
    on Aug 12, 2026
  21. lnicola
    added a commit that references this issue on Aug 17, 2026

    Rollup merge of #160472 - bushrat011899:io_documentation_v2, r=nia-e

    172c3df

  22. NamorNiradnug commented on Aug 21, 2026

    @NamorNiradnug
    NamorNiradnug
    on Aug 21, 2026

    A thought on Read in core. Consider the following solution:

    // core::io
pub trait Read { ... }

// alloc::io
pub trait Read: core::io::Read { ... }

// std::io
pub trait Read { ... }
impl<R: core::io::Read> Read for R { ... }

    This seems to be non-breaking and allows new code to implement core::io::Read and alloc::io::Read while remaining compatible with the existing code that requires std::io::Read. It is quite close to the "perfect" solution that requires auto impl:

    // core::io
pub trait Read { ... }

// alloc::io
pub trait Read: core::io::Read {
    auto impl core::io::Read;
    ...
}

// std::io
pub use alloc::io::Read;

    We could use the first solution until auto impl arrives and then switch the the second one. The switch should be non-breaking (at least I don't see what could break). The only issue I see is that the first solution encourages users to write

    impl core::io::Read for MyRead { ... }
impl alloc::io::Read for MyRead {} // this line is not nice

  23. tisonkun commented on Sep 7, 2026

    @tisonkun
    tisonkun
    on Sep 7, 2026
    Contributor

    I wonder after #160951, we may stablize core::io::Write as well since it doesn't have the issue as io::Read has?

    It helps downstream project to avoid std dependency if only std::io::Write is involved. For example, https://github.com/fast/hashcrew/blob/dbf7916c5da3927edf4bef35c1b2d4db7ded866d/hashcrew/src/xxhash/xxh64.rs#L247-L259.

  24. ojeda
    added a commit that references this issue on Oct 2, 2026

    rust: kbuild: add `no_io_statics` to `core-cfgs`

    5479489
  25. pawelchcki
    added a commit that references this issue on Oct 6, 2026

    feat(library-config)!: make libdd-library-config no_std compatible (#…

    7717de8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCS-tracking-unimplementedStatus: The feature has not been implemented.T-libsRelevant to the library team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions