# OffsetArrays, inbounds, and confusion

**URL:** <https://discourse.julialang.org/t/offsetarrays-inbounds-and-confusion/81295>\
**Category:** Internals & Design\
**Tags:** indexing, arrays\
**Created:** [May 19, 2022, 3:50am UTC](https://discourse.julialang.org/t/offsetarrays-inbounds-and-confusion/81295 "2022-05-19T03:50:46Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [May 19, 2022, 11:43am UTC](https://discourse.julialang.org/t/offsetarrays-inbounds-and-confusion/81295/10 "2022-05-19T11:43:31Z")

</div>

The cat is out of the bag, the question is what to do about it now, and I proposed badges (see my new proposal below, which is not mutually exclusive with it):

> [@Badge for generic-safe/OffsetArray-safe packages](https://discourse.julialang.org/t/badge-for-generic-safe-offsetarray-safe-packages/81270):
>
> Most packages are safe (with or without @inbounds) when used with regular arrays. I do not want to get people to alarmed, but most packages are likely unsafe when the user uses OffsetArray.jl and passes such an array in, so I propose a badge people could put on their package to signal it safe. The implication, if not there, unsafe (or not known to be so). Note, there are also badges for CI testing, that imply the code is tested while misleading. It’s not clear what is tested, just that those t…

> [@fft](#):
>
> As someone coming from C++/python it is perfectly clear the implications of @inbounds

The problem is you could have been aware of the problem and made legal code with it (for all arrays), but then the assumptions broke with the `OffsetArrays` package (and Julia 1.4). And now all who use the macro (or even if not, just take in `AbstractArray` or `AbstractVector`) will need to think about its use (and test for it) too. I’m not sure people will, that seems to be the fatal flaw for renaming to `@unsafe_inbounds`, with many people only taking regular 1-based arrays into account.

You really want to support `AbstractArray` for other reasons, e.g. sparse, Vandemonde matrices or whatever, and most of those alternative array types are still 1-based, but different storage formats.

`OffsetArray` is a different kind, orthogonal to the other alternative arrays, can e.g. be combined with Vandermonde.

I’m thinking could we solve this problem by introducing a different abstract array type in the hierarchy?

Had we done from the start (not too late?) problem averted:

```julia
abstract type AbstractArbitraryArray <: Any end

abstract type AbstractArray <: AbstractArbitraryArray end # would in this
proposal disallow non-1-based

const AbstractAArray = AbstractArbitraryArray # maybe good to have, as short indicating OffsetArrays ok

```

---

_[View the full topic](https://discourse.julialang.org/t/offsetarrays-inbounds-and-confusion/81295)._