Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
We may assume that a `OneTo` behaves like a `UnitRange` on promotion. With this, custom `AbstractUnitRange` types don't need to define promotion rules with `OneTo`, and the following works out of the box: ```julia julia> struct MyUnitRange{T} <: AbstractUnitRange{T} range::UnitRange{T} end julia> Base.first(r::MyUnitRange) = first(r.range) julia> Base.last(r::MyUnitRange) = last(r.range) julia> Base.size(r::MyUnitRange) = size(r.range) julia> Base.length(r::MyUnitRange) = length(r.range) julia> Base.getindex(r::MyUnitRange, i::Int) = getindex(r.range, i) julia> promote(MyUnitRange(3:4), Base.OneTo(4)) (3:4, 1:4) ``` There is some potential for ambiguity if a package defines `promote_rule(::AbstractUnitRange, ::CustomUnitRange)`, in which case a working `promote_rule(::OneTo, ::CustomUnitRange)` becomes ambiguous. However, a similar problem exists for `UnitRange` as well, and I think the benefits outweigh the risks. Co-authored-by: N5N3 <2642243996@qq.com>
- Loading branch information