Should there be an AbstractOneTo type (with OneTo <: AbstractOneTo) that packages can subtype?

[jishnub]

The OneTo type was introduced keeping OffsetArrays in mind, so that the package may add methods to Base functions such as reshape for AbstractUnitRange arguments, while Base does the same for OneTo. The situation is complicated by StaticArrays adding SOneTo which behaves exactly like a OneTo. The problem with this is that OffsetArrays performs type-piracy, and the behavior of StaticArrays methods might change with OffsetArrays loaded.

The solution to this seems to be to have an AbstractOneTo type in Base, and define the Base methods for AbstractOneTo instead of OneTo. StaticArrays can then subtype AbstractOneTo, and always use Base methods irrespective of whether OffsetArrays is loaded.

[goretkin]

x-ref: #41853

(unify <:AbstractRange by using a generic StepRange with a static start and step)

[chriselrod]

If this were a trait instead, then this could also apply to ArrayInterface.OptionallyStaticUnitRange{StaticInt{1},<:Any} .