Skip to content

Conversation

@MoSal
Copy link

@MoSal MoSal commented Dec 14, 2025

In patterns where an insertion directly follows a removal, this serves
as being more efficient, since it only shifts/copies values as needed
for the combined operation.

This also comes with the added bonus of not needing to check for
fullness, and thus, a Result is not needed as a return type.

Copy link
Contributor

@zeenix zeenix left a comment

Choose a reason for hiding this comment

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

LGTM otherwise, thanks!

src/vec/mod.rs Outdated
assert!(remove_index < length);
assert!(insert_index < length);

unsafe {
Copy link
Contributor

Choose a reason for hiding this comment

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

  • Can we have multiple unsafe blocks with each having as little scope as possible?
  • Please adds Safety: comments above each use of unsafe, briefly describing how the invariants are being held in the block.

Copy link
Author

Choose a reason for hiding this comment

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

Pushed a commit that does this (unsquashed, in case I overdid the explanations).

@sgued
Copy link
Contributor

sgued commented Dec 17, 2025

Do you know why this is not also available in the standard library's Vec? This would actually not even need to be implemented on Vec and could be implemented on &mut [T], making it more generic.

@MoSal
Copy link
Author

MoSal commented Dec 17, 2025

@sgued
I asked myself that actually.

Anyway, I relayed this to zulip. And slice methods rotate_left()/rotate_right() make this much simpler (commit incoming).

@MoSal
Copy link
Author

MoSal commented Dec 20, 2025

I added this as a local trait implemented for AsMut<[T]> types in the project where I needed this and moved on.

Feel free to do with it whatever you want. The implementation using rotates is slower as noted a few days ago. So, only the original impl is actually useful performance wise.

@zeenix
Copy link
Contributor

zeenix commented Dec 22, 2025

Feel free to do with it whatever you want. The implementation using rotates is slower as noted a few days ago. So, only the original impl is actually useful performance wise.

I understand that you yourself no longer need this but please consider the time reviewers put into this as well. It seems to me like all that's left now is reverting to the original implementation (git reflog to find the commit, git reset --hard THE_COMMIT_HASH to revert to that and then git push --force)?

 In patterns where an insertion directly follows a removal, this serves
 as being more efficient, since it only shifts/copies values as needed
 for the combined operation.

 This also comes with the added bonus of not needing to check for
 fullness, and thus, a `Result` is not needed as a return type.

Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
@MoSal
Copy link
Author

MoSal commented Dec 22, 2025

@zeenix
Squashed.

Copy link
Contributor

@zeenix zeenix left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!

@zeenix
Copy link
Contributor

zeenix commented Dec 22, 2025

I'm a bit baffled by the CI failure. I can't reproduce the warning locally. 🤔

@sgued
Copy link
Contributor

sgued commented Dec 22, 2025

This is a bug in 1.92 I think, you may not have the latest compiler.

@sgued
Copy link
Contributor

sgued commented Dec 22, 2025

Given that this is a feature that can be implemented on slices, I'm not fully certain it makes sense to merge it here? I'd rather try to get it implemented upstream in core. As #635 (comment) points it can be implemented downstream too, so I'm not sure it should be merged as-is.

@sgued
Copy link
Contributor

sgued commented Dec 22, 2025

Hmm, no this does not reproduce for me either

@sgued
Copy link
Contributor

sgued commented Dec 22, 2025

This might be related: rust-lang/rust#147648

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants