Could someone help me understand why for the given example fn

(defn my-fn [selector]
  (condp = selector
    1 :b
    2 :c
    false))

(s/fdef my-fn
        :args (s/cat :selector any?)
        :ret #{false :b :c})

(s/fdef my-fn
        :args (s/cat :selector any?)
        :ret (s/or :a #(= % false)
                   :b #(= % :b)
                   :c #(= % :c)))

prolly comes down to this: (s/valid? #{false 😛 :c} false) -> false or (#{false} false) -> false

since it will return the value matching in the set (false) this will break

typical quirk with Sets

Is there some established/idiomatic way to use spec with core.async? Particularly when reading from a channel?

Or would it come down to adding a spec to a function that pushes on to the channel you are reading from?

Probably way too broad of a question… lol

@looveh so in short, use contains? (and specify a custom :gen if you need to)

@mpenet Ah, that’s quirky indeed, thanks!

unless you have a transient collection, for which contains? doesn’t work

@camdez thanks for last week's answer about clojure.spec.alpha/invalid in the context of spec's code stability 🙂

@matan You’re very welcome. I hope it was helpful.

@camdez yes, it certainly was!

@camdez will I bump into a lot of stuff coming from its "alpha" namespace when using spec today?

@matan I don’t think you’ll run into much.

Am I correct in thinking that spec would be the wrong tool to assert relationships between keys in a map. For example, lets say we're representing a bill split between n folks, can/should you leverage spec to assert that the sum of amounts under the payees key is greater than or equal to the top-level amount? If not spec, is there some other library that allows you to organize validations like these in a way that lends support to generating good error messages

{:amount 60
 :payees [{:name :andy
           :amount 20}
          {:name :rich
           :amount 20}
          {:name :alex
           :amount 20}]}

seems fine to me, could be a (s/and (s/keys ...) sum-amounts>=total?)

then it's just pattern matching on the explain to return something more "flat" for error messages (depending on your usage), which you can do with/without spec (you could build it with a spec errors conformer that maps to your precise error types)

agree with @mpenet. i don't think it's the wrong tool at all. just a predicate!

Doh! It never occurred to me that (s/keys) could be anded.

@cddr https://github.com/xsc/invariant this looks better for that

on the contrary, I really don't think you need a library to describe a datastructure -- this is literally the rationale for clojure.spec

what cddr wants is a predicate that applies to a collection

Similar to how fspec provides the :fn spec that relates a function's :args and :ret

you're trying to define an invariant about a data structure, not a contract. I like the idea of separating those concepts (thus using a library to define invariants looks like a good idea)

but yeah, that's just being pedantic, so for a simple structure like this, I agree adding a new dependency is probably an overkill

I definitely prefer using the standard lib when it supports what I'm trying to do. Cheers for the suggestion though. Looks interesting 🙂

I think invariant is just a library for defining data structure predicates. if you have to write enough/complicated enough data structure predicates I think it would be useful to use with spec. similar to how specter is useful if you've got to do enough deeply nested data manipulation

@cddr yeah, it is! I'm probably biased towards it because I used it and liked it a lot hahaha. In my case, I had to define invariants on a custom markup language

so spec wasn't going to help there

is it possible to define a spec for map keys without defing a separate spec for each key? I guess what I have in my head is something like:

(s/keys :req-lit {:first-name string?
                  :last-name string?
                  :email (s/and string?
                                #(re-matches email-regex %))})

I think that's an intentionally excluded feature

is there anywhere where I could read up on why that's the case?

https://clojure.org/about/spec - “Map specs should be of keysets only”