clojure.set different behaviour depending on the position of nil

Question

If a nil reaches, e.g., clojure.set/union or clojure.set/intersection, the output depends on the position. I think those functions should give back always a hash-set, irrespective of nils or the position of nil.

$ clj
Clojure 1.10.3
user=> (require '[clojure.set :refer [intersection union]])
nil
user=> (union #{} nil)
#{}
user=> (union nil #{})
nil
user=> (intersection #{} nil)
#{}
user=> (intersection nil #{})
nil
user=> (union #{} nil nil)
nil
user=> (union nil #{} nil)
nil
user=> (union nil nil #{})
#{}
user=> (intersection #{} nil nil)
nil
user=> (intersection nil #{} nil)
nil
user=> (intersection nil nil #{})
#{}

I think the order of the arguments shouldn't matter and should always be a set, in my opinion, just assuming nil as an empty set. Plus if one intends to call later (set-of-things thing) an exception might arise (this is what bit me).

And maybe this is not limited to union and intersection only and more functions have this "issue"

Answer 1

The documentation for the functions union and intersection says what they do when given sets as inputs. The Clojure core developers, when asked in the past about behavior that some developers find to be unexpected or undesirable when given non-sets as input, have said that you are using the functions in a way that promise no particular return value.

You can of course define your own functions similar to union and intersection that provide additional error checking of inputs, and/or define the behavior you want given other non-set input values, as done in this little example library (which I believe no one uses): https://github.com/jafingerhut/funjible

Answer 2

I suspect changing any of these behaviors would potentially be a breaking change if someone relied on the current (undefined) behavior. Would need a lot more investigation about potential impact.