# Does \`AbstractArray\` itself need to support indexing beyond 1-based?

**URL:** <https://discourse.julialang.org/t/does-abstractarray-itself-need-to-support-indexing-beyond-1-based/83324>\
**Category:** Internals & Design\
**Tags:** indexing\
**Created:** [June 25, 2022, 1:26am UTC](https://discourse.julialang.org/t/does-abstractarray-itself-need-to-support-indexing-beyond-1-based/83324 "2022-06-25T01:26:43Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [July 5, 2022, 11:48pm UTC](https://discourse.julialang.org/t/does-abstractarray-itself-need-to-support-indexing-beyond-1-based/83324/16 "2022-07-05T23:48:24Z")

</div>

This was a great talk that touched on a lot of details with very cool proposed approaches, but I’m resolving the thread because I’m now more convinced about equal support for offset indices. What really tipped the scale was [this comment](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/314) pointing out that a `DimensionMismatch` error can be thrown for unmatched axes in general, and I figured it’s not much on top of `DimensionMismatch` errors being thrown for 1-based axes of different lengths.

I still think it would be easier to write `(n÷2+1):n` than `((end-begin+1)÷2+begin):end` (maybe `end-begin+1` could be given its own keyword to correspond to `length`?), but features have tradeoffs and `require_one_based_indexing` is always an option.

---

_[View the full topic](https://discourse.julialang.org/t/does-abstractarray-itself-need-to-support-indexing-beyond-1-based/83324)._