Deprecate r + 1 in favor of r .+ 1

[timholy]

This was giving incorrect results for r .+ 1 (it "erased" the axes), because the old correct implementations were for r + 1. I should have noticed this as part of #7, but failed to do so.

So, this is a breaking change. Will release as 0.3.

[timholy]

@mbauman, for Base.IdentityUnitRange we currently have

julia> r = Base.IdentityUnitRange(-2:2)
Base.IdentityUnitRange(-2:2)

julia> r .+ 1
-1:3

julia> axes(r .+ 1)
(Base.OneTo(5),)

Compare with this PR:

julia> r = IdentityRange(-3:3)
IdentityRange(-3:3)

julia> r .+ 1
7-element OffsetArray(::UnitRange{Int64}, -3:3) with eltype Int64 with indices -3:3:
 -2
 -1
  0
  1
  2
  3
  4

There is no type in Base that can represent the correct answer, so should we just have it throw an error?

[mbauman]

Oh dang. That's unfortunate. Yup, I agree — we can't keep doing what we were doing.

The problem stems from the use of Abstract[Unit]Range here: https://github.com/JuliaLang/julia/blob/5533f22d8f9a1ba8b6ed5d67eac8d54824489d6a/base/broadcast.jl#L1010

All these abstract range definitions will be wrong for an offset range like Slice and IdentityUnitRange. :-\

[timholy]

Presumably we could make them conditional on having unit axes, so that one can specialize those methods and make them work. Perhaps OffsetArrays could engage in a bit of type-piracy and provide the correct implementations?

[mbauman]

That sounds reasonable to me — on both points. It feels a little messy, but I guess we could just dispatch to an internal function that also takes the axes of the given abstract range. That'd allow us to default to an error and allow OffsetArrays to recover the functionality gracefully (well, as gracefully as a peg-legged pirate can be).

[mbauman]

Also wrong are .*, ./, and .\. We may want to check other functions for AbstractRange specializations, too — we often just recompute a range whole-cloth based on start/step/stop and totally ignore anything about the axis.

[timholy]

Thanks for pointing out the errors on .* etc, that still wasn't right here either.

[timholy]

we could just dispatch to an internal function that also takes the axes of the given abstract range. That'd allow us to default to an error and allow OffsetArrays to recover the functionality gracefully

Actually, if we can, let's have the AbstractRange (or other abstract type) implementations just check and then throw an error. Anyone who is going to provide the correct implementation will use the concrete type, so it will get precedence. Maybe a little less ugly that way?

[mbauman]

Yeah, that requires OffsetArrays to know all concrete offset range implementations. I suppose there are a very limited number, though, so this probably isn't worth the extra contortions.

Another bug: ==.

[timholy]

Another bug: ==.

Here it was mostly correct because of the first(r) == first(s) == 1, but better would be first(r) == first(s) == first(axes(s)[1]).

[mbauman]

Ah, nice. We still need to change it in Base, though... that was my bigger concern.