range map-broadcast inconsistency

[aplavin]

# for -: broadcast returns a range, map materialized
julia> .-(1:3)
-1:-1:-3

julia> map(-, 1:3)
3-element Vector{Int64}:
 -1
 -2
 -3

# for type: map returns a range, broadcast materialized
julia> Float64.(1:3)
3-element Vector{Float64}:
 1.0
 2.0
 3.0

julia> map(Float64, 1:3)
1.0:1.0:3.0

Not sure which behavior is intended, but it could use more consistency I guess.

[jariji]

Both of these functions have a rather wide interface, so the inconsistency doesn't violate any requirement of their specification afaict.

It would be nice if they guaranteed the output type match the input type, but that's rather out of reach in 1.x I think. #32081

[aplavin]

the inconsistency doesn't violate any requirement of their specification

Sure, same as Julia inferring anything as Any.

However, this is still an inconsistency, quite an unintuitive one: there's no single answer to what has a better "chance" of preserving a range, f.(x) or map(f, x).

[nsajko]

For general f, neither f.(range) nor map(f, range) can return back a range. Thus this requires special-casing the function (or type) f. An endless game of whack-a-mole?

[aplavin]

Thus this requires special-casing the function (or type) f. An endless game of whack-a-mole?

Totally, I agree with you here.
Would prefer something like islinear() trait for functions that makes both f.(::Range)::Range and map(f, ::Range)::Range...

But here we are working with the current situation. This special-casing exists in Julia already, as seen from the examples above.
This map vs broadcast split makes it impossible to predict the return type of such functions, and makes this optimization completely non-discoverable.