Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.47%. Comparing base (b361279) to head (287c1aa).

@@               Coverage Diff               @@
##           release-1.0     #337      +/-   ##
===============================================
+ Coverage        95.42%   95.47%   +0.05%     
===============================================
  Files               17       17              
  Lines             1530     1548      +18     
===============================================
+ Hits              1460     1478      +18     
  Misses              70       70              

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

Looks like there are some downstream test failures caused by adding an extra type parameter to BlockedUnitRange.

Probably a non-breaking implementation needs to be in the non-standard form BlockedUnitRange{R,T}, where T is obtained from R in the inner constructor.

I’m thinking we tag v1 after this is done so it’s fine if it’s breaking

I’m thinking we tag v1 after this is done so it’s fine if it’s breaking

I'm guessing that most use cases of BlockedUnitRange can be replaced with BlockedOneTo, for example axes of most AbstractBlockArray subtypes should be BlockedOneTo, and also blockedrange should output BlockedOneTo (see related discussion in #334). Perhaps it is better to wait for a v1 release after those changes are made?

Yes sorry I meant tag v1 once we also add BlockedOneTo

I think this is ready for review. Some discussion points are:

1. What should the element types of blocklengths and length be? Currently they are the eltype of the BlockedUnitRange, but that could be changed. It seems to be conventional for length to be Int in Julia, but that choice probably doesn't make sense for ranges, since they can be BigInt or even infinite length. There are tests of the types of the outputs of the various block axes interface functions so you can see the current behavior.
2. I've refactored the constructors of BlockedUnitRange to make sure that the fields r.first and r.lasts have types consistent with the element type (and each other). My strategy was to promote r.lasts to a common type if it is a tuple (i.e. it is converted to an NTuple), and also convert r.first to eltype(r.lasts) if needed.
3. How should this be coordinated with the developed of a BlockedOneTo type (and also possibly a AbstractBlockedUnitRange supertype)? Ideally that would use this as a starting point, but merging this into the master branch commits the master branch to making a breaking change, which likely should be put off until a v1 release. Could this get merged into a new v1 branch where further v1 developments like BlockedOneTo can occur?

1. length for BigInt ranges returns a BigInt, so I don't think we need to be constrained to Int.
2. Yes, we should create a branch for v1 and change the base branch for this PR to point to that. I'm also planning a BlockedOneTo PR soon (it's almost ready at this point).

There already appears to be a release-1.0 branch from a year back. Could you change the target branch of the PR to that one?

Gentle bump, could you rebase this on the updated release-1.0 branch?

Will do.

@jishnub I merged the latest release-1.0 into this branch.

I assume we will want to generalize the element type of BlockedOneTo in a similar way but it seems like that could be done in a follow-up PR.

In the latest commit I made the type constraints of the inner _BlockedUnitRange constructors stricter, so that first and lasts are expected to have more uniform types, and outer constructors use type promotion to make the types more uniform, for example now there is this behavior:

julia> BlockArrays._BlockedUnitRange(UInt8(1), [1, 2, 3])
3-blocked 3-element BlockedUnitRange{Int64, Vector{Int64}}:
 1
 ─
 2
 ─
 3

julia> BlockArrays._BlockedUnitRange(UInt8(1), (UInt8(1), 2, 3))
3-blocked 3-element BlockedUnitRange{Int64, Tuple{Int64, Int64, Int64}}:
 1
 ─
 2
 ─
 3

whereas before the types of the fields first and lasts where not uniform in those cases. Let me know if you think that is the right behavior, and the right way to design that code logic. The way I went about it involved constraining the type of the lasts field to either be a Tuple or AbstractVector, which seems reasonable but I'm not sure if you have other cases in mind for what the field might be.

I think this looks good at this point. There are some issues like last(blockedrange(2, UInt(1):∞)) throwing errors, but these may not be related to this PR and may be addressed separately. At this point, we just need tests for the flagged lines for which coverage is missing.

I think this looks good at this point. There are some issues like last(blockedrange(2, UInt(1):∞)) throwing errors, but these may not be related to this PR and may be addressed separately. At this point, we just need tests for the flagged lines for which coverage is missing.

Sounds good, I'll add some more tests to improve the coverage.

Ok I think everything is covered now.

Great, let's merge this and then figure out the other issues