issubset aces Discrete Math but flunks Topology

[timholy]

#26198 did some fantastic performance tuning of issubset based on a very thorough analysis of scaling behavior. However, the change implicitly assumed that the "superset" is countable, specifically that length is defined and will return an integer value. Ranges are an example of a container for which this succeeds (this example leverages the fact that numbers are iterable):

julia> r = 1:3
1:3

julia> issubset(2, r)
true

julia> issubset(4, r)
false

So far so good. However, length can't be reasonably defined for many mathematical sets, and as a consequence bad things happen in issubset:

julia> struct OpenInterval{T}
           lower::T
           upper::T
       end

julia> Base.in(x, i::OpenInterval) = i.lower < x < i.upper

julia> issubset(3, OpenInterval(2, 4))
ERROR: MethodError: no method matching length(::OpenInterval{Int64})
Closest candidates are:
  length(::Core.SimpleVector) at essentials.jl:571
  length(::Base.MethodList) at reflection.jl:728
  length(::Core.MethodTable) at reflection.jl:802
  ...
Stacktrace:
 [1] issubset(::Int64, ::OpenInterval{Int64}) at ./abstractset.jl:230
 [2] top-level scope at none:0

This PR addresses the issue in a minimalistic fashion: it checks the IteratorSize trait of the superset, and skips the performance-tuning block if length can't reasonably be expected to succeed.

This isn't an ideal solution, because HasLength() is the default, but at least it gives package authors a means to avoid the bad behavior.

[oscardssmith]

does this work with testing if open intervals subset other open intervals?

[timholy]

does this work with testing if open intervals subset other open intervals?

Assuming an OpenInterval is not iterable, no. But that's fine, because the docstring of issubset is

help?> issubset
search: issubset

  issubset(a, b)
  ⊆(a,b)  -> Bool
  ⊇(b, a) -> Bool

  Determine whether every element of a is also in b, using in.

so issubset isn't expected to work in that case. But we do need a way to live up to the promise of just testing against in; the performance-tuning shouldn't break the fact that there is a very simple definition that does work.

(EDIT: the docstring doesn't preclude a specialized definition, of course. But there isn't a reasonable fallback definition if the first argument isn't iterable.)

[rfourquet]

There is already a function defined for that: Base.haslength(r) ;-)

[timholy]

Updated to use haslength. With two approvals and no objections, I think we can merge this once it gets through CI again (it passes locally).