Fork me on GitHub

Is nil considered valid input for Clojure set functions? 0 arity returns empty set, but 1 arity with nil returns nil


In other words should a spec for those functions account for nil input or throw


@borkdude Could you show some code? I'm not sure what you're asking.


(set/union) vs (set/union nil), they differ in return type


set/union is only defined for arguments that are sets tho', right?


(and nil is not a set -- so it's "garbage-in, garbage-out" here?)


So I guess the answer to your question is "No, a spec for those functions should not allow nil as input".


If we can agree for union etc. that 1) :ret should be set? then we must either 2) reject nil inputs in the :args spec, or 3) assert that the implementation is wrong


maybe @alexmiller can say something on this


would we find it useful for fdefs detect nil (as an instance of non-sets) inputs for set fns?


or can we say this is undefined territory and assume the simpler spec

Alex Miller (Clojure team)16:11:36

I think right now I would treat both inputs and output as nilable

Alex Miller (Clojure team)16:11:48

as existing code may be relying on the behavior of those things


if we don’t allow nil, we will find out 🙂

Alex Miller (Clojure team)16:11:12

if your spec fails on working existing code, I think your spec is wrong


true, but I mean, we can actually discover if people use this in the wild and then adapt the spec accordingly

Alex Miller (Clojure team)17:11:47

I don’t know how else to say it

Alex Miller (Clojure team)17:11:41

you asked for my opinion. My opinion is that you should spec the inputs and output as nilable.


yes, I wondered why you disagree with adapting the spec gradually when we discover that people actually use those fns like that


but maybe we can rightaway assume people do this

Alex Miller (Clojure team)17:11:29

nils are often used interchangeably with empty collections. it seems unlikely to me that there is not some code relying on this either for input or output


next case…

(clojure.set/union 3)


the identity function….


I think it’s safe to assume people do not use the 1-arity as the identity function 😉

Alex Miller (Clojure team)17:11:52

I think you can figure that one out


thanks for the replies


Is there a recommended way of running stest/check in a deftest? I looked around and couldn't see anything official, just lots of different ways people did it


@danielcompton if there is I’d like to know, because I’m doing that right nw


@danielcompton I’m trying to write tests for clojure, cljs and self-hosted cljs all within one .cljc file. Guess what, all three environment expect and return different keys for the clojure.test.check opts/rets.


@borkdude, @danielcompton There was a short discussion about that yesterday. People suggested using test.chuck (not a typo) or separating your property based tests out and run them separately.


This is mainly because I'm curious, but does anyone now why the args passed to :fn in s/fdef are conformed values? I'd like to use the actual value in there, but dealing with the conformed value is tricky.


@bmaddy does test.chuck support .cljc?


I've never used it, but the readme says this in the Acknowledgements section: @nberger for adapting to cljc format for ClojureScript, and general maintenance help


@borkdude Fine detail nit on your earlier questions -- in the implementation there are calls at least clojure.set/union, and perhaps a couple of other clojure.set functions, with sequences as arguments (the return value of the clojure.core/keys function IIRC), so not a set and not nil. I believe the implementation of clojure.set/union for the ways they are called from always return correct results (i.e. duplicates in the return value are only harmful for performance, not correctness of the results). Not sure if that is considered a bug or something that an 'official' spec for clojure.set/union should allow. I am an interested observer of such detailed questions, too, not a policy maker.


OK, I've just added a comment to that issue with a copy/paste of what I just said above.

👍 4