Fork me on GitHub

(s/keys ::req []) <- notice the :: instead of :req is there a way to have that throw an error ? sometimes, I define that, then I create objects, and they satisfy the spec ... because it's a map with no requirements since ::req is silently ighnroed


would that not go against the "accept arbitrary extra keys" philosophy of spec?

Alex Miller (Clojure team)18:11:34

I wouldn’t necessarily put it in the spec for keys, but it’s reasonable to validate it in the function. It’s not like this is getting passed to anything else.


I spose I had always interpreted the openness as partially targeting forwards-compatibility

Alex Miller (Clojure team)18:11:33

It’s still forward compatible to accept more stuff in the future


right, but then code targeting the future API can't use the older version if it happens to be around maybe that's not a useful thing? you just want backwards compatibility so you can use the newest of all the versions that each part of the code wants?

Alex Miller (Clojure team)21:11:08

I would say that’s a non-goal


(s/fdef s/keys
        :args (s/+ (s/cat :k #{:req :opt}
                          :v coll?)))
=> clojure.spec.alpha/keys
(s/keys ::req [])
CompilerException clojure.lang.ExceptionInfo: Call to clojure.spec.alpha/keys did not conform to spec:
In: [0] val: :user/req fails at: [:args :k] predicate: #{:req :opt}
 #:clojure.spec.alpha{:problems [{:path [:args :k], :pred #{:req :opt}, :val :user/req, :via [], :in [0]}], :spec #object[clojure.spec.alpha$regex_spec_impl$reify__2436 0x2fa7a99c "[email protected]"], :value (:user/req []), :args (:user/req [])}, compiling:(/tmp/form-init4270935507983081845.clj:1:1) 
(s/keys :req [])
@qqq @gfredericks sure. But you can do 🙂 Maybe in future versions of spec, this spec will be wrong. But for now, it's a usefull build-time error.


but there's a difference between spec setting that spec on s/keys and a user doing it themselves


Before I go write one, is there a generator for specs? i..e one that will generate (s/cat :x int?)

Alex Miller (Clojure team)21:11:01

The spec specs in CLJ-2112 are imo the right direction for that. The specs there are not yet good enough to be used for this in general


Not quite. I'm testing, so I want to throw arbitrary specs at it


once there's a spec spec you could presumably get a generator from it


shouldn't spectrum have a spec spec already anyhow? I say that as someone who has never used spectrum


It only needs s/spec? as a spec when using spectrum. To test it, I want a spec generator


curious if there’s been any thought/discussion/work for sharing specs (besides putting them in a shared library)


something akin to XSD? I suppose it’d be limited to what can be expressed in whatever format

Alex Miller (Clojure team)21:11:23

The whole point of using fully qualified namespace keys is that everyone can share specs


yeah, I guess my curiosity is more about alternative mediums/mechanisms for sharing specs?


but as soon as you use custom predicates, you need to share code as well

Alex Miller (Clojure team)22:11:37

Which is also fully qualified


I’m thinking of something conceptually similar to Swagger I guess. And yeah it would be a pretty limited subset of spec’s abilities.