Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.67%. Comparing base (1e5feaa) to head (eb95d65).

@@           Coverage Diff           @@
##           master     #429   +/-   ##
=======================================
  Coverage   93.67%   93.67%           
=======================================
  Files          18       18           
  Lines        1643     1643           
=======================================
  Hits         1539     1539           
  Misses        104      104           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I can confirm that this resolved the type-instability in #426 , thank you!

As a small comment, that I rejected myself after going through the actual implications, but might want to leave here for future reference.

As an additional suggestion, this might also not be unreasonable, and further improve the type-stability in the case of block arrays with BlockedOneTo axes:

Currently, the combination of this definition and this definition imply that the following things don't coincide:

a = rand(3)
blockaxes(a, 1) # BlockRange(Base.OneTo(1))
blockaxes(a, 2) # Base.OneTo(1)
blockaxes(axes(a, 2), 1) # BlockRange(Base.OneTo(1))

To me it seems like the latter is a much more reasonable fallback for "trailing indexes", and this would resolve the type-instability for the typical BlockArray cases.

This suggestion does not really work because I didn't fully realize that a[Block(1), 1] and a[Block(1), Block(1)] do not actually mean the same thing (the former is a vector, the latter a matrix).