Curtis Vogt

I've been making some PRs to Julia to use more specific function calls which avoids triggering invalidations in base when using Intervals.jl. These changes won't address invalidations that occur with...

Probably is safe to update these to be: ```julia Base.:(==)(a::T, b::Endpoint::T) where T = a == b.endpoint && isclosed(b) Base.:(==)(a::Endpoint{T}, b::T) where T = b == a ``` Not quite...

> Got another one: > > ```julia > inserting convert(::Type{T}, interval::Intervals.AnchoredInterval{P, T, L, R} where {L

More specifically this package could just add the anchored interval support. I don't believe IntervalSets.jl supports unbounded intervals currently.

> Alternative. > We swap to using `is_open` and `is_closed` > Which follow the style guide. > and we can explort them as they don't conflict with Base. > >...

Another example where `is_open` would be worse is if someone would write: ```julia is_open(interval1) && issubset(interval1, interval2) ``` Seems like an unnecessary inconsistency

I did some experimentation with `@boundscheck` and couldn't get it to work with this code. Additionally, I think using `@inbounds` here is misleading as what we really want to indicate...

I believe that we need to enforce that the left precedes the right. To remove that enforcement we would need to review the entire package to ensure there are no...

The behaviour is currently deprecated: ```julia julia> Interval(0, -1) ┌ Warning: Constructing an `Interval{T,X,Y}(x, y)` where `x > y` is deprecated, use `Interval{T,Y,X}(y, x)` instead. │ caller = Interval at...

I think the behaviour is coming from `max`: ```julia julia> max(Interval(2,6), Interval(3,5)) # Expecting `Interval(2,6)` Interval{Int64}(3, 5, Inclusivity(true, true)) julia> max(Interval(3,6), Interval(3,5)) # Expecting `Interval(3,6)` Interval{Int64}(3, 5, Inclusivity(true, true)) julia>...