Fork me on GitHub
#clojure-spec
<
2019-11-28
>
Alex Miller (Clojure team)00:11:19

That’s on the table for spec 2

Alex Miller (Clojure team)00:11:54

But they are likely to be significantly different than spec 1

bbloom02:11:33

@alexmiller Could you please clarify: “That’s” == what exactly?

Alex Miller (Clojure team)02:11:37

specs integrated into defn

👍 8
bbloom02:11:12

ah, ok, just wanted to be sure that’s what you meant 🙂 very cool. looking forward to seeing what you folks come up with

didibus02:11:28

Why is there no support for and/or inside of s/keys :opt ?

didibus02:11:27

(s/keys :req-un [::a]
        :opt-un [(and ::b ::c)])

didibus02:11:59

In my case, ::b and ::c are optional, but if anyone of them is there, the other has to be as well

Alex Miller (Clojure team)02:11:07

Because optional things are ... optional

Alex Miller (Clojure team)02:11:31

You’ll need to s/and another predicate if you have additional constraints

didibus02:11:19

Hum.. its just more annoying, because the combinations to list out with s/and can quickly grow

didibus02:11:52

but that's what I'll do for now

didibus02:11:44

I guess I need s/or

didibus02:11:19

s/or (s/keys :req-un [::a]) (s/keys :req-un [::a ::b ::c])

didibus03:11:53

Hum... its a lot trickier then I thought

didibus03:11:58

Or I'm tired

didibus03:11:56

(s/or :one (s/keys :req-un [::a]) :two (s/keys :req-un [::a (and ::b ::c)])
This means that the following is valid as well:
{:a :b}
Because the first s/keys is open.

gordon16:11:38

You could do something like this, which doesn't require you to list all possible optional combinations

👍 4