Is OffsetArrays.jl a poison pill?

Internals & Design
21

What sort of problems do you envision?

There’s no AbstractTuple type, so there’s no code that expects 1-indexed tuples, and could be surprised by 0-based tuple input. Only if a function accepts general iterables, could an OffsetTuple be used unexpectedly, and then the code must anyway deal with OffsetArrays, so you would need general indexing. I don’t think anyone would be bothered by someone registering OffsetTuples.jl.

The issue isn’t which packages exist, but what properties can you rely on for abstract types that you want to support. Tuples do, but AbstractArray and iterables in general do not, guarantee 1-based indexing. It should therefore be as easy as possible to work with them, and mostly it is. for a in A is totally general; eachindex(A) is at least as simple as 1:length(A), certainly easier to type; axis(A, 1) is simpler than 1:size(A, 1), etc. It’s when you don’t want to just loop over all elements that it gets a bit harder, then you have begin, end, firstindex, lastindex, first, last, …

But maybe there could be some very simple and universal way to get a one-based view into any AbstractArray? OffsetArray has no_offset_view, but should all AbstractArrays have a method like that? Then anyone who wants less hassle would just write

function foo(A0::AbstractArray)
    A = OneBasedView(A0)
    for i in 4:length(A)-3
        ...
    end
end

Could this be made even simpler? Could there be some way to facilitate automatic promotion to OneBased? A @one_based macro, a new keyword, for1? (just kidding, maybe.)

2 Likes