What sort of problems do you envision?
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
But maybe there could be some very simple and universal way to get a one-based view into any
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.)