Feedback: The relationship between `push_back` and `insert`/`insert_full` is a bit confusing

[bgw]

insert_full and push_back have identical implementations and near-identical descriptions.

https://github.com/indexmap-rs/ringmap/blob/main/src/map.rs#L405-L437

This was a bit confusing to me. I'm guessing the insert-style API is there for compatibility with indexmap and hashmap's APIs, but the push_back API makes more sense for a VecDeque.

I feel like you should pick one style of API and deprecate the other? At the least, the documentation should explain that they do the same thing.

I'm personally trying out this library because of the VecDeque-style aspects of it, so I'd prefer the push_back API.

Thanks for this library, and of course indexmap. We use indexmap pretty heavily in Turbopack because we need predictable iteration order for our caching layer to work effectively.

[cuviper]

Hi, thanks for trying this! I was sweeping through pretty quickly when I ported the IndexMap code, so I'm not surprised that I left some duplication, and there may be other inconsistencies as well. Hey, this is why it's still v0.1. :)

I think you're probably right that we should deprecate all the insert methods that really push back. We can leave others like shift_insert though. And for cases like VacantEntry::insert_entry, we need a push front/back variant to be added!

I'm glad to know Turbopack uses indexmap, and I'll be interested to hear if ringmap works out too!
(whether for that or something else)

[bgw]

We did end up using it to replace a hacky custom DequeSet implementation! vercel/next.js#80867