@potetm feel free, although I don’t know that there is much need :)

@jasonjckn backwards compatible changes do not necessarily require a new spec (for example, s/keys will always validate all registered keys, so adding new ones does not require a spec change)

@jasonjckn breaking changes should mean a new spec

I expect this area will receive more attention as its something Rich has thought about a lot

and he’s really serious about not just “changing” specs but actually leaving the existing one and creating a new one (::person2, ::person3, etc)

the evils of “using the same name to refer to different things"

hello immutable data

😄

has anyone managed to do the “take a spec, walk it and transform it to another (differently conforming) spec”? I tried, but for s/keys it seems hard/impossible. Have already copied much of the clojure.spec internals into my project for this. With un-keys, it’s easy, with the non-un keys, it’s not: the key names should remain same, with a different implementation.

would be nice, if there was a map-kind of Spec in clojure.spec that would allow separate keys and values - I could just swap the values in this case. Could there be such a thing under the hoods of s/keys @alexmiller?

@ikitommi having a consistent meaning for a namespaced keyword is one of the core ideas of clojure.spec

ikitommi's question relates to my earlier one about whether conformed values are more or less intended to remain internal to the function in which they were conformed.

When used idiomatically, anyway.

@gfredericks true that, but for external input, there is a need to conform/coerce values differently, based on capabilities of the wire format. Stuarts thought was to transform raw specs into new specs, with different conformers.

How would that preclude you from using different keys for the new specs, ikitommi?

what if I want to expose a fully-qualified key?

for unqualified keys, I can just create a new spec key, e.g. :mydomain/age => :JSON.mydomain/age, as both can be mapped to the use the :age key.

Hi! I play with spec and found one dangerous point. I use s/fspec to specify high-order function foo with bar argument. In several cases I may call foo with bar that have some side effects. When instrument is enabled then bar will be called more than onсе because spec will check bar. For instance I may write smth like that: (foo delete-user-by-id) and debug it many hours. I can check only bar arity but stest/check will not work.

(ns spec.func.example
  (:require [clojure.spec :as s]
            [clojure.spec.test :as stest]))

(defn foo [bar]
  (bar 42))

(s/def ::bar (s/fspec :args (s/cat :x integer?)
                      :ret integer?))

(s/fdef foo
  :args (s/cat :bar ::bar)
  :ret integer?)

(stest/instrument)

(foo #(do
        (println %) ;; print more than once !!!
        (inc %)))

@kuzmin_m I've been dealing with exactly this

you might not want to use check at all, but instrument with its :replace option, and then call the function normally

Yes. But people are careless. If something is breakable it’ll be broken.

I may forget specify replace option

not sure what you mean

I need an extraordinary action. I need remember about s/fspec behaviour and specify instrument option.

May we write a function that replace s/fspec by fn? when we use instrument? We don’t call fn and we only check an argument type in this case.

@kuzmin_m that would make instrument significantly less useful

fwiw, I think there should probably be more explicit handling of functions with side-effects for both fspec and fdef, and I'm hopeful that something is coming

Sure! But it only about fspec, not about fdef.

they're kinda the same thing though, fdef as far as I understand it is just (s/def name (s/fspec blah))

Yes. I just write about one case: s/fspec for function argument.

right, I just mentioned fdef because you can use the name of something fdef'd somewhere in place of an fspec and you'll get the same behaviour. but anyway you're right that it would be on fspec where things need to be handled

right 👍 I forget about that behavior 😞

It’s just alpha version. I hope that we can fix this issue.

is there a “best practices” way to run spec tests from lein?

i found this https://gist.github.com/tgk/be0325e7b78bc692ad6c85ef6aca818d

have you seen summarize-results? https://github.com/clojure/clojure/blob/master/src/clj/clojure/spec/test.clj#L448

i haven’t seen official guidance on the one true specifically correct invocation of clojure.spec.test/check, but when i dig around in github search i usually see people write clojure.test assertions like (is (= 0 ((summarize-results foo) :failures))) or whatever

handwaving here, but you get the idea

It works well with Cursive’s run tests REPL action

Example usage:

(t/defspec-test st-test-name `you-function-to-test)