::OrdinalRange .* ::Integer returns a StepRangeLen (which is no longer OrdinalRange)

[arnaud-ma]

For example

julia> typeof((1:2:10) .+ 4) # works fine
StepRange{Int64, Int64}

julia> typeof((1:2:10) .* 4)
StepRangeLen{Int64, Int64, Int64, Int64}

It can be an issue for functions that only requires OrdinalRange. For example

julia> CartesianIndices((1:10) .* 4, 1:10)
ERROR: MethodError: no method matching CartesianIndices(::StepRangeLen{Int64, Int64, Int64, Int64}, ::UnitRange{Int64})

I think the easy fix would be to write this:

julia/base/broadcast.jl

Lines 1139 to 1140 in e65af91

	broadcasted(::DefaultArrayStyle{1}, ::typeof(+), r::OrdinalRange, x::Integer) = range(first(r) + x, last(r) + x, step=step(r))
	broadcasted(::DefaultArrayStyle{1}, ::typeof(+), x::Integer, r::OrdinalRange) = range(x + first(r), x + last(r), step=step(r))

but for typeof(*), and by also multiplying the step to have the same behavior.

[martinholters]

I think the problem is that (1:2:10) .* 0 cannot be represented as a StepRange, so for type stability, we always return a StepRangeLen, even if the result could be represented as a StepRange.

[mikmoore]

That it should return a StepRangeLen for type stability seems unavoidable. But I don't think that's necessarily the end of the story as far as CartesianIndices is concerned.

Once again we encounter the pitfalls of types-as-traits. CartesianIndices is too strict here. It could at least attempt to convert a StepRangeLen{<:Integer} (which is an OrdinalRange in every criterion except <:) to a StepRange. One could go so far as to suggest it should support AbstractRange{<:Integer} generally -- I don't see profound harm in a CartesianIndices with a step of 0 in one or more axes.

[martinholters]

Maybe convert(::Type{StepRange{...}}, ::StepRangeLen) could be defined, which would throw an InexactError when appropriate?