# Is OffsetArrays.jl a poison pill?

**URL:** https://discourse.julialang.org/t/is-offsetarrays-jl-a-poison-pill/85188
**Category:** Internals & Design
**Created:** [August 2, 2022, 7:22pm UTC](https://discourse.julialang.org/t/is-offsetarrays-jl-a-poison-pill/85188 "2022-08-02T19:22:53Z")
**Posts on this page:** 1
**Showing post:** 28

<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: [August 3, 2022, 9:21am UTC](https://discourse.julialang.org/t/is-offsetarrays-jl-a-poison-pill/85188/28 "2022-08-03T09:21:43Z")

</div>

As someone who was in the “1-based to rule them all” camp for a while during that discussion, I can totally see the appeal of separating `OffsetArrays` somehow. But I came to realize some things:

1. There’s no decree to use or support `OffsetArray`s, and we can totally write `1:n` syntax in that case. We even have the `require_one_based_indexing` function to check inputs. Funnily enough, if there’s a custom array type that isn’t 1-based, `OffsetArray`s can make it 1-based to be compatible with your 1-based code.

2. `OffsetArray`s are actually important. You should see the cool examples on the Julia blog post introducing them, but it’s not hard to run into math where starting at 1 doesn’t make sense. We’d have to do offset calculations to get to the index we need anyway, why not make a wrapper type do it automatically?

3. Why shouldn’t `OffsetArray`s work in `AbstractArray` code? Many functions really could work with any indices, and some functions currently marked with `require_one_based_indexing` actually could work with offset indices, just require that all inputs share compatible ones. Incompatible indices can just throw the existing `DimensionMismatch` error.

4. We definitely should make a docs section or tutorial that teaches people right away how to write “generic” indices; people might not be as good as indexing arrays as they think. (Even the devs! The `OffsetArray` discussion revealed some overflow bugs when indices or related values get too close to `typemax`/`typemin`.) It’s not a big deal when you’re just indexing from `begin` to `end` (and in that case, just call `eachindex(A)` or `axes(A, i)`), but it gets real important when you start doing fancy stuff like indexing the “middle”, skipping every other index, or going backwards. Obscure errors happen when different key quantities that happen to have the same values are confused with each other, like an `n` meaning the last index vs. an `n` meaning length. In 0-based indexing, this is actually more annoying because there are invisible `0+` everywhere that you have to spot to edit the indexing order. `begin/end` syntax could be improved to make these distinctions easier, and even if you don’t do offset indices you’d reach for the generic syntax just for clarity.

---

_[View the full topic](https://discourse.julialang.org/t/is-offsetarrays-jl-a-poison-pill/85188)._