This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # aws (3)
- # beginners (150)
- # boot (12)
- # calva (7)
- # carry (3)
- # cider (1)
- # clara (51)
- # cljdoc (17)
- # cljs-dev (17)
- # cljsrn (1)
- # clojure (64)
- # clojure-austin (2)
- # clojure-india (1)
- # clojure-italy (10)
- # clojure-nl (4)
- # clojure-spec (42)
- # clojure-uk (63)
- # clojurescript (24)
- # core-async (23)
- # cursive (6)
- # datascript (7)
- # datomic (5)
- # figwheel-main (43)
- # fulcro (74)
- # hoplon (7)
- # kaocha (30)
- # leiningen (32)
- # mount (51)
- # nrepl (34)
- # off-topic (29)
- # re-frame (6)
- # reagent (10)
- # reitit (13)
- # shadow-cljs (66)
- # slack-help (3)
- # spacemacs (2)
- # specter (5)
- # sql (2)
- # tools-deps (51)
- # yada (13)
Is nil considered valid input for Clojure set functions? 0 arity returns empty set, but 1 arity with nil returns nil
@borkdude Could you show some code? I'm not sure what you're asking.
set/union is only defined for arguments that are sets tho', right?
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?
I think right now I would treat both inputs and output as nilable
as existing code may be relying on the behavior of those things
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
I don’t know how else to say it
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
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
I think it’s safe to assume people do not use the 1-arity as the identity function 😉
I think you can figure that one out
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
s/fdef are conformed values? I'd like to use the actual value in there, but dealing with the conformed value is tricky.
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 clojure.data/diff 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
clojure.data/diff always return correct results (i.e. duplicates in the return value are only harmful for performance, not correctness of the clojure.data/diff results). Not sure if that is considered a bug or something that an 'official' spec for clojure.set/union should allow. https://dev.clojure.org/jira/browse/CLJ-1087 I am an interested observer of such detailed questions, too, not a policy maker.
@andy.fingerhut Please include these notes at https://github.com/slipset/speculative/issues/70
OK, I've just added a comment to that issue with a copy/paste of what I just said above.