Looks like we got a tip on eliminating that warning.
Something I'd be interested in is a (m/case) where I solemnly swear there's no overlap & I don't care about order.
I have a (m/match) like:
(m/match
{::anom/category ::anom/unavailable} {:status 503}
{::anom/category ::anom/interrupted} {:status 500
:retry? true})
Which then generates one big fast case statement. However, if I switch each statement to an m/or
(m/or {::anom/category ::anom/unavailable}
{:exoscale.ex/type :exoscale.ex/unavailable}) {:status 503}
because m/match preserves order, it degrades to (essentially) a cond check (kinda, it uses case with default causes to fall back onto other keys).
I haven't benched the performance, but I'm assuming it's slower than a pair of case statements.For now, I'll probably copy/paste as my then is pretty small.