Tracking Issue for `alloc::io` and `core::io`

[a1phyr]

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.)

• ACP (accepted): ACP: Introduce alloc::io libs-team#755
• Implementation:
  • Move IoSlice and IoSliceMut to core::io #155849
  • Move std::io::ErrorKind to core::io #154654
  • Move std::io::RawOsError to core::io #155574
  • Move std::io::Error into core #155625
  • Migrate rest of std::io to alloc #154684
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

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

[Mark-Simulacrum]

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).

[Amanieu]

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.

[bushrat011899]

Provided Error can be moved into core::io, it's possible to move Seek and SeekFrom into core::io as well, except there is one blocker: impl Seek for Arc<File> { ... }. File cannot be moved into alloc or core (well, I don't think it could...), and Arc is not a fundamental type. Making Arc fundamental interferes with TryFrom<Arc<[T], A>> for Arc<[T; N], A>, so that's not viable either.

An alternative that compiles is to replace the Seek implementation for Arc<File> with a more general impl<T> Seek for Arc<T> where for<'a> &'a T: Seek. This works, but obviously adds a new blanket implementation with the potential for breakage.