Equality of empty ranges

[sostock]

In order to be equal, ranges need to have the same first element, last element, and step, even if they are empty. Beside being unintuitive, this also breaks the transitivity of ==:

julia> 2:1 == 1:0
false

julia> 2:1 == Int[] == 1:0
true

[nalimilan]

There's likely a historical reason to this: before #16401, arrays and ranges could never be equal, so there was no transitivity issue. We should definitely change that IMHO.

[mschauer]

This is a reasonable change, but it would be at odds with the searchsorted interface, for which the elements of an empty range have a meaning and shouldn't compare equal

julia> searchsorted([1.0,2.0,3.0],2.5)
3:2

julia> searchsorted([1.0,2.0,3.0],2.5) == 2:1
false

[nalimilan]

Yes, that's related to #22354. But I don't think that's a problem here. The result of searchsorted gives you additional information via the start and end values of an empty range, but it's also correct to ignore that information and just say that the value wasn't found.

[nalimilan]

Marking for triage since that would be technically breaking.

[mauro3]

But isn't == supposed to be transitive? If so, this would be a bug.

[StefanKarpinski]

Yes, we can definitely make that case but we still have to consider the consequences. Definitely need discussion in any case.

[StefanKarpinski]

Triage generally feels that these should be made == and isequal. We make things value-equal all the time that have details which differ and this seems no different. Transitivity of equality is more important. Would need a PkgEval run to see what if anything breaks.

[JeffBezanson]

I generally agree with that but searchsorted does kind of throw a monkey wrench into it.

[StefanKarpinski]

I'm a bit hazy on when you would compare the result of searchsorted like that. Can someone thing of realistic example of that kind of usage?

[mschauer]

In interpolation at i = searchsorted(v, x), checking for i == 1:0 or i == n+1:n to special case boundaries seems natural.