Gustavo Goretkin

Could you include an example? It will help someone fix this issue in the future.

With https://github.com/JuliaDiff/ForwardDiff.jl/pull/247 @tkoolen's test pass; is that because the generated tags are simpler, thereby hiding the type inference bug? slightly off-topic: Is there a recommended (use-at-risk-of-perturbation-confusion) fallback that lets me...

That is the only reasonable definition of `in`, I agree, and furthermore it's consistent with a bunch of other set operations defined on `Interval`, like `intersect` (and to a [lesser...

Thanks for pointing me to https://github.com/gwater/NumberIntervals.jl . I suspected it would have the same inconsistency since `NumberInterval in(0.5, NumberInterval(0.0, 1.0)) true julia> my_in(element, collection) = any(==(element), collection) my_in (generic function...

I was curious about other interval packages, and it seems like the three others I found are not `

There are some issues with `Quantity{Interval}`: ```julia using IntervalArithmetic: IntervalArithmetic, interval using Unitful: Unitful, m a = interval(0, 0) b = interval(0, 1) @assert a

Perhaps this is not the place to collect violations of the interface informally suggested by `

Ideally it would benefit from https://github.com/JuliaIntervals/IntervalArithmetic.jl/pull/421 to avoid the same issues.

I suppose there are two separate issues, one is consistency in which some operations have an implicit "hull" and others do not. The other issue is about type closure. It...

> Dictionary-like containers would define `get(::ContainerType, key)` while we need `get(obj, ::Lens)`. This would introduce ambiguities. I think I just ran into this ambiguity, but for a different reason (because...