Stabilize Seek::stream_position (feature seek_convenience)

[LukasKalbertodt]

Tracking issue: #59359

Unresolved questions from tracking issue:

• "Override stream_len for File?" → we can do that in the future, this does not block stabilization.
• "Rename to len and position?" → as noted in the tracking issue, both of these shorter names have problems (len is usually a cheap getter, position clashes with Cursor). I do think the current names are perfectly fine.
• "Rename stream_position to tell?" → as mentioned in the comment bringing this up, stream_position is more descriptive. I don't think tell would be a good name.

What remains to decide, is whether or not adding these methods is worth it.

[LukasKalbertodt]

FYI: a new discussion potentially arguing against stabilization just emerged in the tracking issue.

[SimonSapin]

Highfive is configured in https://github.com/rust-lang/highfive/blob/master/highfive/configs/rust-lang/rust.json#L6, and this list (in particular my absence from it ;)) is deliberate.

r? @kennytm

In general though the right time for a stabilization is after FCP has happened, because of cases like this:

a new discussion potentially arguing against stabilization just emerged

[LukasKalbertodt]

Highfive is configured in https://github.com/rust-lang/highfive/blob/master/highfive/configs/rust-lang/rust.json#L6, and this list (in particular my absence from it ;)) is deliberate.

Oh, oops. I simply checked https://www.rust-lang.org/governance/teams/library to see if kennytm is in the libs team, didn't see them listed there and assumed this was a highfive bug. Sorry!

In general though the right time for a stabilization is after FCP has happened, because of cases like this:

I assumed that FCPs mostly happen on the PR and not the tracking issue. At least I think that that's mostly what I saw so far. I even considered asking for FCP on the tracking issues instead of creating a PR but decided against it because I thought FCP on PR is the "proper" way to do it. If you want, I can close this PR until FCP is complete.

[Dylan-DPC-zz]

r? @dtolnay

[dtolnay]

@rust-lang/libs:
I don't have a strong opinion either way on this one, but I am open to accepting these methods. I would be interested what you all think. Some of us weighed in previously in #58422 (comment) when these were originally implemented.

• https://doc.rust-lang.org/1.43.0/std/io/trait.Seek.html#method.stream_len
• https://doc.rust-lang.org/1.43.0/std/io/trait.Seek.html#method.stream_position

@rfcbot fcp merge

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @SimonSapin
• @dtolnay
• @sfackler
• @withoutboats

Concerns:

• non-atomic-tell (Stabilize Seek::stream_position (feature seek_convenience) #70904 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[sfackler]

@rfcbot concern non-atomic-tell

stream_position seems totally reasonable to me (maybe modulo a rename), but I'm not really a huge fan of stream_position being implemented by 3 seeks. It's unfortunately non-atomic and (almost?) every seekable construct of finite length should have a more "proper" method to return its length.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[pthariensflame]

since attribute needs updating.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[m-ou-se]

@bors r+ rollup

[bors]

📌 Commit 8a18fb0 has been approved by m-ou-se