Add std::io::cursor::WriteThroughCursor

[bushrat011899]

ACP: rust-lang/libs-team#755
Tracking issue: #154046
Split From: #156527

Description

Used to work around Cursor not being a fundamental type when implementing Write for Cursor<Vec<u8>> and other alloc types once Cursor and Write are both located in core. Please refer to #156527 for further context.

---

Notes

• No AI tooling of any kind was used during the creation of this PR.
• Please see Tracking Issue for alloc::io and core::io #154046 (comment) for a review order and broader context for this PR.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ChrisDenton, libs
• @ChrisDenton, libs expanded to 13 candidates
• Random selection from 6 candidates

[clarfonthey]

So, I'm not sure this PR itself is worthwhile separating from #158541, since it appears that you move this trait into core in that PR. Moving isn't tracked very well in git, especially when things aren't absolute file renames, and so I'm kind of inclined to just say that this should be part of that PR instead of this one.

That is also the largest PR of the bunch post-split, and I wonder if it should be further split up into parts, rather than this being the only "part" split off of it.

[bushrat011899]

I've started a conversation about this matter on Zulip since it's probably better suited for workshopping a solution. Linking here for transparency.

[clarfonthey]

So, main concern is this unfortunately isn't going to be shown under the implementations for Write, and I'm not really sure what the best way to deal with that is. rustdoc doesn't really seem to have a method to create "fake" impls for docs only, so maybe there should be some kind of issue tracking a way to deal with this.

View changes since the review

[bushrat011899]

Yeah I think there would need to be some kind of "flatten" feature for listing implementations. Ignoring instability for a moment, adding this trait would hide the Write implementations for:

• Cursor<&mut Vec<u8, A>> where A: Allocator
• Cursor<Vec<u8, A>> where A: Allocator
• Cursor<Box<[u8], A>> where A: Allocator

And would instead show:

• Cursor<T> where T: WriteThroughCursor

Which would require users to visit WriteThroughCursor to see it is implemented for:

• &mut Vec<u8, A>
• Vec<u8, A>
• Box<[u8], A>

Ideally, we could do something like:

#[doc(flatten = "T")]
impl<T: WriteThroughCursor> Write for Cursor<T> { /* ... */ }

To recreate the original flat documentation.

[Mark-Simulacrum]

r? @clarfonthey (happy to take the review but as you mentioned elsewhere might make sense to batch-review a bunch of these PRs)

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[clarfonthey]

I think that the discussion from Zulip was compelling enough that we can merge this separately; essentially, this technically changes the behaviour of implementations and can be useful for bisection in case of issues, even though the actual code will show up as completely moved on diffs.

Given that this does not conflict with other core::io changes:

@bors r+ rollup=iffy

Marking as rollup=iffy mostly for visibility with the other core::io changes. While this and #158540 shouldn't conflict, not sure this should be added to the rollup if the other one which already includes that PR fails.

[rust-bors]

📌 Commit cae0245 has been approved by clarfonthey

It is now in the queue for this repository.