Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for core_io_borrowed_buf #117693

Open
2 of 4 tasks
jmillikin opened this issue Nov 8, 2023 · 5 comments
Open
2 of 4 tasks

Tracking Issue for core_io_borrowed_buf #117693

jmillikin opened this issue Nov 8, 2023 · 5 comments
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@jmillikin
Copy link
Contributor

jmillikin commented Nov 8, 2023

Feature gate: #![feature(core_io_borrowed_buf)]

This is a tracking issue for an MVP of core::io, which contains an OS-independent subset of std::io.

Public API

The initial API of this module consists of BorrowedBuf and BorrowedCursor, which were previously only available in std.

Steps / History

Unresolved Questions

  • None yet.

Footnotes

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

@jmillikin jmillikin added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Nov 8, 2023
@jmillikin jmillikin changed the title Tracking Issue for core::io Tracking Issue for core_io_borrowed_buf Nov 8, 2023
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Nov 8, 2023
…m-ou-se

Move `BorrowedBuf` and `BorrowedCursor` from `std:io` to `core::io`

Tracking issue: rust-lang#117693

ACP: rust-lang/libs-team#290
TaKO8Ki added a commit to TaKO8Ki/rust that referenced this issue Nov 9, 2023
…m-ou-se

Move `BorrowedBuf` and `BorrowedCursor` from `std:io` to `core::io`

Tracking issue: rust-lang#117693

ACP: rust-lang/libs-team#290
TaKO8Ki added a commit to TaKO8Ki/rust that referenced this issue Nov 9, 2023
…m-ou-se

Move `BorrowedBuf` and `BorrowedCursor` from `std:io` to `core::io`

Tracking issue: rust-lang#117693

ACP: rust-lang/libs-team#290
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Nov 9, 2023
Rollup merge of rust-lang#117694 - jmillikin:core-io-borrowed-buf, r=m-ou-se

Move `BorrowedBuf` and `BorrowedCursor` from `std:io` to `core::io`

Tracking issue: rust-lang#117693

ACP: rust-lang/libs-team#290
cpu added a commit to cpu/rustls-ffi that referenced this issue Nov 15, 2023
Unbreaks builds using the read_buf feature.
Tracking issue: rust-lang/rust#117693
@tgross35
Copy link
Contributor

tgross35 commented Feb 26, 2024

These types in core could use a core::fmt::Write impl, but I am not sure how this is possible without conflicting with the blanket impl for std::io::Write.

@taralx
Copy link
Contributor

taralx commented Mar 16, 2024

Is the intent to stabilize this at the same time as #78485 or independently of it?

@kornelski
Copy link
Contributor

kornelski commented Jun 5, 2024

I'm surprised that this doesn't have any safe integration with Vec. I'd like to have vec.as_borrowed_buf() that can safely append to the uninitialized capacity, without having to manually perform unsafe vec.set_len correction afterwards.

@keepsimple1

This comment was marked as resolved.

@keepsimple1
Copy link

keepsimple1 commented Aug 13, 2024

If I understand, BorrowedBuf (like MaybeUninit) essentially is safe to write, may I suggest adding a method to the API of BorrowedBuf:

/// Copies the bytes of `buf` to self starting at `offset`.
///  Returns the number of bytes actually written.
///
/// If `offset` is equal or larger than `self.buf.len()`, returns 0.
/// If `offset` is larger than `self.init`, the region `self.buf[self.init..offset]` is zeroed. 
pub fn write(&mut self, offset: usize, buf: &[u8]) -> usize

(this method updates filled and init accordingly)

The idea is to make the API even easier to use:

  • Simpler: no need to use BorrowedCursor for such use cases.
  • No need to use different APIs to write filled / init section and uninit sections.
  • No panics (from this method) as it returns the written length.
  • Compatible with existing API.

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants