Fork me on GitHub
Alex Miller (Clojure team)00:08:54

per the s/fdef doc string, ” :args A regex spec for the function arguments as they were a list to be passed to apply - in this way, a single spec can handle functions with multiple arities”

Alex Miller (Clojure team)00:08:35

or I guess maybe the confusing thing is that regex ops nested inside each other are combined to describe the same sequential collection

Alex Miller (Clojure team)00:08:21

so you have an effective foo args spec of (s/cat :aa (s/cat :name keyword?)), however nested s/cats like this combine to form a spec for a single sequential collection (the args list)

Alex Miller (Clojure team)00:08:49

what you’re wanting is that ::any-args described a new nested collection

Alex Miller (Clojure team)00:08:54

you can do that with (s/fdef foo :args (s/cat :aa (s/spec ::any-args)))

Alex Miller (Clojure team)00:08:09

the s/spec wrapper here forces a new (non-combined) collection level


Thanks, Alex. Got it.


@alexmiller Is there any issue with using (s/spec ...), or unintended side effects? I'm thinking about defn-spec, within Orchestra, which provides fn specs inline. It seems like defn-spec should expand every arg spec to be wrapped in s/spec, based on your explanation.


I've run into issues with regex flattening in arg-specs so I think you're right here


(w.r.t. using s/spec how you've described)


Since none of them should ever flatten to affect the outer s/cat for the :args.

Alex Miller (Clojure team)02:08:08

I can’t speak to what Orchestra or defn-spec does, sorry. There are possible use cases for wanting the flattening here, although I agree that’s probably unusual.


We were discussing a bit on #clojurescript about having the possibility to specify a custom printer (a la *explain-out*) for check results.


Is it something worth working on, or at least opening a JIRA about?