# Map and set getters to give a way to get an item at an order

**URL:** <https://es.discourse.group/t/map-and-set-getters-to-give-a-way-to-get-an-item-at-an-order/2541>\
**Category:** 💡 Ideas\
**Created:** [April 16, 2026, 9:11am UTC](https://es.discourse.group/t/map-and-set-getters-to-give-a-way-to-get-an-item-at-an-order/2541 "2026-04-16T09:11:50Z")\
**Posts on this page:** 1\
**Showing post:** 33

<div class="post-metadata">

**Author:** ![Jingcong](https://avatars.discourse-cdn.com/v4/letter/j/8797f3/32.png) [@Jingcong](https://es.discourse.group/u/Jingcong)\
**Post date:** [May 22, 2026, 6:20am UTC](https://es.discourse.group/t/map-and-set-getters-to-give-a-way-to-get-an-item-at-an-order/2541/33 "2026-05-22T06:20:27Z")

</div>

Thanks for the engine-level analysis — this is really valuable.

A few thoughts:

1. **O(n) is fine** : `Array.prototype.at` is O(1) because arrays are contiguous. For Maps/Sets, O(n) is acceptable as long as it's documented. Developers already pay O(n) when they do `[...map.keys()][n]` : but they also pay O(n) memory. `.at(n)` would be O(n) time but O(1) memory, which is still a win.
2. **JSC could optimize later** : Even if it's O(n) today, nothing prevents JSC from changing to a flat array in the future. The API doesn't mandate performance, just behavior.
3. **Polyfill concern** : You're right, but that's true for many proposals. Developers can feature-detect and use native when available, fall back to their own array otherwise. The existence of a polyfill doesn't block the proposal.

Really appreciate you digging into the engine details. This is exactly the kind of discussion I was hoping for.

---

_[View the full topic](https://es.discourse.group/t/map-and-set-getters-to-give-a-way-to-get-an-item-at-an-order/2541)._