Add pushfirst! and popfirst! methods for OffsetVectors

[GregPlowman]

No description provided.

[codecov]

Codecov Report

Merging #192 (005e509) into master (b20b4db) will decrease coverage by 1.76%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #192      +/-   ##
==========================================
- Coverage   99.28%   97.51%   -1.77%     
==========================================
  Files           5        5              
  Lines         280      282       +2     
==========================================
- Hits          278      275       -3     
- Misses          2        7       +5     

Impacted Files	Coverage Δ
src/OffsetArrays.jl	96.82% <100.00%> (-2.11%)	⬇️
src/axes.jl	97.95% <0.00%> (-2.05%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b20b4db...005e509. Read the comment docs.

[fredrikekre]

See #78, #137

[GregPlowman]

With pushfirst!/popfirst!, my worry is that the natural thing to do would be to mutate the initial index

Okay, that is not what pushfirst!(::Vector) does though?

Right, pushfirst! on a vector does not mutate the initial index. So we could say that this is just how pushfirst! works. I could agree to that.

OTOH Vector lies in that fuzzy world spanning both views of 1-d arrays, either "I'm just a list of elements" or "I'm an associative container with integer keys." pushfirst! seems to belong to the first world, but most uses of OffsetArrays are probably in that second world.

While I'm sympathetic to both views, I wouldn't say that "most uses of OffsetArrays are probably in that second world".
We might, for example, want a list starting with index 0?

In any case, if we agree that pushfirst! belongs to the first world ("just a list of elements"), then we shouldn't "confuse" that meaning when operating on OffsetVectors. If that first world meaning is not what you want, then use a different function?

Since there are 2 concepts here, does it make sense to have 2 functions?
pushfirst! is the first world meaning and is consistent with pushfirst! on Vectors (doesn't mutate first index)
pushreverse! changes starting index

Or perhaps a keyword argument?

[timholy]

We might, for example, want a list starting with index 0?

I have been puzzled about why I have never seen evidence of anyone creating a ZArrays.jl package. I created the ZeroRange (like Base.OneUnit, but starting at 0) about 5 years ago, basically to help quiet the seething masses who complained about Julia having chosen 1 for its array indexing, but as far as I know it's still waiting for the first customer. https://github.com/JuliaArrays/CustomUnitRanges.jl

Given that a dedicated ZArrays package could be used to handle the case you mentioned, that does leave more room for OffsetArrays to be focused on a world where "location matters." Do you have a need for pushfirst! besides 0-indexed arrays?

You probably noticed this in the links that @fredrikekre kindly shared, but if not the BidirectionalVector in CatIndices is roughly how an array class supporting pushfirst! on offset arrays should work.

[GregPlowman]

OK I'm happy to pass on this.
I get the preference for the second world where location matters when dealing with OffsetVectors.
I just thought that conflating this meaning with pushfirst! is not ideal, and a separate function would be clearer.