Jishnu Bhattacharya

Yes for indices that are `OffsetArrays` wrapping `AbstractUnitRange`s, we do presently convert them to `IdOffsetRange`s in the indexing operation. The performance matters when the parent indices are not `AbstractUnitRange`s, eg....

I'm in support of the trait-based approach, although I realize it's a lot of work. Suggesting an user to be conscious of types seems far from ideal. Also adding a...

Gentle bump @dlfivefifty

Gentle bump @dlfivefifty

For the record, this performance match is obtained on v1.9. The performance is still somewhat inferior on v1.8. On v1.9 ```julia julia> x = Fill(2, 300, 300); julia> @benchmark [i...

I'm in favour of removing these convenience methods in `OffsetArrays` 2.0. With the new `Origin` type, these aren't inconvenient to create anymore.

Perhaps we need to retain the convenience of `zeros(indices)` in some way. Currently, the ways to construct such an array is * `OffsetArray(zeros(length), indices)` * `Origin(origin)(zeros(length))` In the first case,...

`offset` has a different meaning in this package (the difference between `firstindex(axis)` and `1`). Perhaps a name like `OffsetAxes` might be clearer and unlikely to clash with other symbols. Then...

Yes, it seems essentially equivalent, except it doesn't subtype `AbstractUnitRange`. Thus, we won't see different behavior for `3:5` and `OffsetArrays.IdOffsetRange(3:5)`. Tbh I'm uncertain what's the best approach here. If we...

Certain parts from this package may be ported to `Base`, such as the `similar` and `reshape` methods, and `IdOffsetRange`. This should provide most functionalities. I'm not certain if we should...