This feature still requires a lot of work, but soon(ish), Expound will be able to provide examples of valid clojure code https://gist.github.com/bhb/f637ef589ef3ac3d2ca5a883fafc2c12

However, this adds a dependency on test.check to use expound at dev time. Would you prefer to have this be a hard dependency OR would you prefer expound to disable this feature if you don’t have test.check available?

@mcama200 spec/keys is a macro so it takes literal code forms, not variables.

What you can do instead is to use the literal vector in s/keys and then call s/form (I think?) on the spec itself and walk that to get the list of required keys back out of a spec definition.

@alexisvincent The short answer is: specs are currently pretty static so you have to have multiple specs -- or specify that :card/cvv is :opt in the base spec and then wrap it in another spec that uses s/and and a predicate that "requires" that key be present.

(s/def :card/full-details (s/and :card/details #(contains? % :card/cvv)))

I guess spec could eat its own dog food?

boot.user=> (s/fdef foo (s/cat :a1 string?))

     java.lang.IllegalArgumentException: No value supplied for key: (s/cat :a1 string?)
clojure.lang.Compiler$CompilerException: java.lang.IllegalArgumentException: No value supplied for key: (s/cat :a1 string?), compiling:(null:1:1)

been there done that: my personal favorite is (s/def foo any?) or (s/fdef ::foo :args (s/cat))

both silently fail, which makes it even better

@seancorfield Thanks for the answer, the s/and is neat, and will help reduce branching factor, but I don’t think it’s a long term behaviour. I can use functions that return specs, but loose out on spec’s repository. Do you know if dynamism will be added to named specs in the future, or if it even needs to be?

I have the current spec (simplified):

(s/fdef widget
        :args
        (s/cat :opts
               (s/keys
                :req-un [::title
                         ::content]
                :opt-un [
                         ::init-collapsed?
                         ::fixed?])))

but they can be both absent as well?

yes

if you say the widget must be fixed, init-collapsed? can not be true, because the widget won’t be visible at all that way

I could just emit a warning outside of spec, but maybe there’s a nice solution

I also don’t want to introduce nesting in the arguments

I could maybe use s/conformer?

I guess you need a separate pred in s/and since opt-un will not accept (or ...) etc

yes,

(fn [m]
  (not (and (:init-collapsed? m)
        (:fixed? m))))

I imagine a multispec could do it too, but that's prolly too much complexity for such as simple check

java.util.concurrent.ExecutionException: clojure.lang.ExceptionInfo: Couldn't satisfy such-that predicate after 100 tries. {}

Most depressing error ever.

agreed :)

unfortunately, the current linkage between spec and test.check prevents good error reporting on where this is happening. there are plans to make this better, but it requires changes in both projects.

@alexmiller I'm curious how what you just described relates to an earlier comment that spec can't enscricten its version requirements of test.check

enscricten = ?

make more scrict

and scrict = ?

opposite of pecmissive

@alexisvincent define all your fields’ specs, and then have several s/keys specs for different combinations of those fields. Then you might want to have the card spec, which is s/or around those s/keys

Remember, you can have keys with different namespaces in the same map/object, so don’t paint yourself into corner with unified namespace “:card” when some attributes might be better named, like :amex.card/number, because it’ll have different spec and generator.