Tracking Issue for `core_io_borrowed_buf`
jmillikin opened this issue · 5 comments
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
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
.
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.
Could you please add a link in the summary to the PR that originally added BorrowedBuf
and BorrowedCursor
? (As both this move and the original changes are unstable, it is somewhat difficult to track back the changes).
I believe the link is: #97015
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 anduninit
sections. - No panics (from this method) as it returns the written length.
- Compatible with existing API.
What do you think?