Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Similar method to Vec.splice #274

Closed
SeaDve opened this issue Sep 4, 2023 · 4 comments · Fixed by #294
Closed

Feature request: Similar method to Vec.splice #274

SeaDve opened this issue Sep 4, 2023 · 4 comments · Fixed by #294

Comments

@SeaDve
Copy link

SeaDve commented Sep 4, 2023

I'm trying to drain a range and then insert multiple items into that gap, where the number of remove items is not always equal to inserted item, basically similar to Vec.splice. If that is not possible, there could also be some method that could insert an item to a particular index, so the behavior of splice could be replicated.

Currently, I do the following to replicate the behavior:

let end_part = inner_index.split_off(position);
inner_index.extend(new_items.chain(end_part.into_iter().skip(n_removed)));
@SeaDve SeaDve changed the title Similar method to Vec.splice Feature request: Similar method to Vec.splice Sep 4, 2023
@cuviper
Copy link
Member

cuviper commented Sep 5, 2023

there could also be some method that could insert an item to a particular index, so the behavior of splice could be replicated.

That's #173 -- the core pieces are there with move_index, at least. But it would be inefficient if you are inserting many items this way.

Currently, I do the following to replicate the behavior:

let end_part = inner_index.split_off(position);
inner_index.extend(new_items.chain(end_part.into_iter().skip(n_removed)));

This is not bad, although we could avoid some extra hashing if we did this internally.

However, if new_items and end_part have any overlapping keys, the latter will replace its value. I would expect you actually want the keep the new_items value -- or maybe you're just sure there's no overlap in your scenario.

let end_part = inner_index.split_off(position);
// this may overlap the beginning keys -- should they move?
inner_index.extend(new_items); 
for (key, value) in end_part.into_iter().skip(n_removed) {
    // This will avoid clobbering any new_items, but should they be
    // in their old (shifted/relative) position or the new spliced position?
    inner_index.entry(key).or_insert(value);
}

@SeaDve
Copy link
Author

SeaDve commented Sep 6, 2023

or maybe you're just sure there's no overlap in your scenario.

Yep, in my use case, it is ensured that there are no duplicate keys.

In general, though, I would expect existing keys to stay where they are; only unique keys are put on the gap, and the non-unique ones are simply used to update existing values at both ends. But, the behavior may be unexpected and might not overlap with other use cases.

A better alternative, I think, is to insert only unique keys (i.e., keys that are not on the map) on the gap, and return the non-unique keys as an iterator, so the caller could choose to use them to update values on the map explicitly, simply ignore them, or use them to assert that all items are inserted on the gap.

@cuviper
Copy link
Member

cuviper commented Jan 13, 2024

If you're still interested, could you give #294 a try?

@SeaDve
Copy link
Author

SeaDve commented Jan 19, 2024

If you're still interested, could you give #294 a try?

I tested it and it works well, thanks!

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

Successfully merging a pull request may close this issue.

2 participants