Reminder: https://github.com/gfredericks/schpec exists and you might like it and it could use some eyeballs 🙂

I’ll probably end up contributing regex-str spec at some point because I gotta write it anyway

What would be an appropriate name for a spec for a string that matches a regex?

Would re-matches and re-find be weird?

My first attempt was matches-re?

I wonder how I’d write the generator for has-re? or whatever; so far I only care about the entire re

I guess I could generate prefix string, re string, suffix string in parallel and then fmap str/join

huh, with-gen has a branch for if the spec is a regex

oh, wait, that means clojure.spec generalized regex, not str regex 🙂

Perhaps this is obvious but I just noticed that cljs.spec doesn’t seem to define an assert macro a la clojure.spec

seems relatively unlikely to be an oversight so I am wondering what I am missing

I guess i can provide my own version of assert*

If I want to always validate a function's input against an fdef spec, do I need to use the clojure.spec.test namespace? Or does the namespacing suggest that eg. clojure.spec.test/instrument is only for use in development and tests and I shouldn't use it otherwise?

@brabster: good question.

@brabster: Maybe you can separate out the args spec and refer to it in the fdef - and then call s/valid? in your function (or hook it up with :pre)?

@borkdude: you're right, I did that but it's quite a lot of extra typing if the individual arg specs aren't really reusable anywhere - and when I use a spec in a precondition the error message doesn't give any details of why the validation failed (just gives the name of the spec)

hmm, I see

plus I seem to frequently end up with what feels like duplication like (s/cat :foo ::foo :bar ::bar :baz ::baz) when I break the specs out - maybe i'm just writing bad clojure or something 🙂

(tbh I'm struggling a little to work out when/when not to use namespaced keywords too :P)

It's quite annoying to get the arguments as a vector that you can validate yourself, isn't it?

without repeating

Yep

Say we have:

(s/def ::my-fn-args (s/cat :n number? :s string?))
(s/fdef my-fn :args ::my-fn-args)
(defn my-fn [n s] (if (s/valid? ;; now what?

I get your point. Following the discussion.

What I'm also a bit uneasy with is that you have to repeat the argument names and that there's a possible source of duplication error.

I imagine there are plans to integrate spec more deeply with core stuff like defn so maybe this is a bit painful because it's early days

It would be cool if you could write a spec and then the function using the spec:

(defn my-fn ::my-fn-args ...)

Looks good to me

With the option to disable at runtime if you want to trade off the safety for slightly faster code

What might be even nicer is combined spec conform and destructuring if that's possible

Thanks for the input @borkdude, more confident I'm not missing something really obvious now 🙂

@brabster: No problem, I'm also just beginning to see the dimension that spec adds to Clojure. Pretty excited about it.

@borkdude: seems really useful ... maybe it should do the conform so you specify something like (defn my-fn [{:keys [destructuring form]} ::my-fn-args] ...) and you could get the destructured pieces in your arguments?

I don't know yet, but something with less boilerplate would be awesome

(defn my-fn #[n number? :s string?] ...)  

(defn my-fn [{:keys ....]] (s/cat :n number? :s string?) ...)

don't know if it makes sense 🙂

looks like a good start on the idea to me!

Is it possible to get the keys out of an s/cat without using exercise?

you can call s/form and grab the odd elements

(->> (s/cat :a string? :b keyword?) s/form (drop 1) (partition-all 2) (map first))

Just for fun: https://gist.github.com/borkdude/8d69f326b3d363a0b34e7b949b039992

borkdude: if you’re doing serious parsing, you may also want to look at spectrum:

https://github.com/arohner/spectrum

spectrum.conform/parse-spec returns defrecords for the vast majority of specs. 100% coverage is a goal

Having an error specing a function that takes a seq of maps. Here’s a gist with a cljc and error. https://gist.github.com/mmb90/e2e33cb526ed8c25549edbdb6e48f711

It seems to think it should be getting a map instead of a seq of maps. Is there a detail I’m missing?

@mmb90: s/* is a regex for zero or more of these specs — so you’re saying name-unicorns takes zero or more arguments, each of which should match the ::unicorn spec.

I think you want s/coll-of for a collection of ::unicorn entities.

@seancorfield: The s/* is inside of an s/cat pulling out the first argument, so I thought the spec said that name-unicorns takes one argument which is a sequence of zero or more ::unicorns entities.

The s/cat is for the entire :args sequence.

In s/fdef you specify :args as a sequence — as if you always invoked the function with apply.

Yes. I understood that aspect, but I didn’t understand the way s/cat and s/* were combining to only specify one sequence. I was understanding as if the s/* were wrapped in s/spec which is required to turn a regex-op into a full spec or predicate.

Does that sound correct?