Fork me on GitHub

I'm stumped on this one—how do I declare that a valid arg is anything fnable, not just fn?? The function params are [pred coll], and I'm not sure how it should be fspecced.


Thanks, that was the ticket!


Does s/def order matter? Can I compose with yet to be defined specs?


It works for me now, at least with keyword spec (instead of predicate function)


@yonatanel the first of your two questions


Is it possible to write custom explanations? At least for a conformer.

Alex Miller (Clojure team)14:11:39

Regarding the earlier question on order - do note that specs delay their resolution, but cache it once they do

Alex Miller (Clojure team)14:11:58

This mostly matters when working at the repl


what are the implications of that? re-deffing a spec requires re-deffing all specs that reference it?

Alex Miller (Clojure team)14:11:10

Yes - if they've been used

Alex Miller (Clojure team)14:11:00

This changed in the alpha that did the perf pass


"been used" like in s/fdef in particular?

Alex Miller (Clojure team)14:11:25

No, like you've conformed with it or done something to force the delay


Not directly related to clojure.spec, but is there a point in namespaced keywords that are values and not keys, other than being used in datomic as enum? I'm conforming some strings to keywords and I wonder if I should conform them directly to their datomic enum form.


How can I define a spec that is like another keys spec but one of the keys is optional this time?

Alex Miller (Clojure team)16:11:17

Or define the simpler one first, then s/merge with another s/keys that reqs the additional key


@alexmiller If the first one has the key in :opt and the second in :req, will the second one override the first?

Alex Miller (Clojure team)16:11:41

There's no overriding - they are both checked and will be satisfied


I can't find a reason to use s/key's :opt if s/keys checks all map keys anyway. The guide says "We’ll see later where optional attributes can be useful" but I couldn't find an explanation.

Alex Miller (Clojure team)16:11:28

It's in docs and it's used for gen


Is it possible to turn on nilable for a whole set of keys, for example if we decide to treat nil values as not existing at all in a certain case?


Conformer to the rescue: (s/def ::no-nils (s/conformer (fn [x] (into {} (filter second x)))))


Along these lines...

Alex Miller (Clojure team)21:11:06

With stuff like this youre just treating spec as a meat grinder rather than actually trying to describe your data.


@alexmiller Interesting point. What's a good use of conformer?

Alex Miller (Clojure team)23:11:57

building composite specs (like keys*)


I'm doing some coercion from standard web api (json) to internal representation, checking that something is a string, trimming it, checking that it's not blank after trimming. Stuff like that. It looks great in clojure.spec.

Alex Miller (Clojure team)23:11:54

as I’ve said many times here - that’s fine. but keep in mind that you are throwing away information when you use conformers like that. When you register a spec like that, you are making a decision for all future users of your spec. That may be fine, but it’s something to be aware of.


There's no way to generate a spec for the conformed values of some other spec, is there?


are people generally putting specs inline? or in separate files/namespaces?