Yuto Horikawa

I'm not sure we need [`eltype` function](https://docs.julialang.org/en/v1/base/collections/#Base.eltype) for non-iterable objects such as `ClosedInterval`. The most consistent way would be rename `eltype(::Interval)` to `boundstype(::Interval)`, I guess.

>Perhaps we could have 1..2 turn into 1.0..2.0, because the notation implies the intention of a continuous set, while leaving Interval(1,2) as it is? We currently support `Date` type, so...

How about `Rational`? I think this should not be converted with `float`.

>Agreed. How about if the bounds are What about boundary_eltype ? Or `boundstype` for short? (https://github.com/JuliaMath/IntervalSets.jl/issues/115#issuecomment-1219278427)

>I want to know what the elements are like - it is a set after all - and the first thing I'd do is abuse boundstype for that purpose :-)...

I have checked some benchmarks, there weren't any degressions. I found some type instability, but this is the same behavior as on the current `master`. ```julia julia> @code_warntype (1 .....

This original issue with `setdiff` can be solved with `complement` in #123.

I was thinking that the `setdiff` method can be defined as `setdiff(i1::Interval, i2::Interval) = intersection(i1, complement(i2))`.

Yes, what I was trying to say is, after introducing the `complement` and `ComplementInterval` by solving #123, this issue can be solved incidentally. The implementation will be like this: ```julia...

How should we implement the lazy version of `setdiff(1..3, 2..4)`? Is it related to #41? I think the behavior (i.e. whether lazy or not) of `setdiff` should be the same...