Skip to content

Use strongly typed wrapped indices in VecDeque#152112

Open
Kobzol wants to merge 3 commits intorust-lang:mainfrom
Kobzol:vec-deque-strongly-typed
Open

Use strongly typed wrapped indices in VecDeque#152112
Kobzol wants to merge 3 commits intorust-lang:mainfrom
Kobzol:vec-deque-strongly-typed

Conversation

@Kobzol
Copy link
Member

@Kobzol Kobzol commented Feb 4, 2026

This is far from perfect, but it would have prevented #151769.

r? @joboet

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Feb 4, 2026
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@Kobzol Kobzol force-pushed the vec-deque-strongly-typed branch from 38ead54 to 5aed3d9 Compare February 6, 2026 19:35
Copy link
Member

@joboet joboet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love the general approach, though I have a couple of nits. And personally I'd chose BufferIndex over WrappedIndex, but I'm fine with whichever you choose.

View changes since this review

pub(super) struct WrappedIndex(usize);

impl WrappedIndex {
/// Safety invariant: the newly constructed index must be in-bounds for the VecDeque
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this safety invariant is particularly useful, as all functions that act on the buffer still need to require that the WrappedIndex is specific to that particular VecDeque with a given capacity.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's a relatively weak invariant. That being said, I still thought it would be a good idea to provide a "SLOW DOWN" sign when someone wants to conjure the index out of the blue, which is why I marked the function unsafe.

}

#[inline(always)]
pub(super) fn abs_diff(self, other: Self) -> Self {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The return type should be usize, right? It isn't a buffer index but rather a length.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, the type represents something like "value in-bounds". My thought process was that if we have two in-bounds values, and we do an absolute diff of them, the result also has to be in-bounds (w.r.t. the same VecDeque). But we do treat it as usize everywhere the function is currently used, so.. I'll change it to usize.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 7, 2026
@Kobzol
Copy link
Member Author

Kobzol commented Feb 7, 2026

I did name if BufferIndex index originally 😆 I guess both works.

@Kobzol
Copy link
Member Author

Kobzol commented Feb 7, 2026

I do slightly prefer the Wrapped name, I think that the buffer part is implied by the word "index". The main idea is to express that the index was wrapped to not go over bounds, which is how it is created through most means.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 7, 2026
@rust-log-analyzer

This comment has been minimized.

@Kobzol Kobzol force-pushed the vec-deque-strongly-typed branch from 72a5f8f to 841763e Compare February 7, 2026 20:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants