@norton it's tricky... you have to make sure there's an fdef for the thing you're :replace-ing

@drewr Thank you for the feedback. I posted this question (with more details) to the Google clojure mailing list with an example that is using :replace. Alex Miller responded and corrected my example. It works as expected!

s/keys question, I need to express key ::foo is optional, but if it's there ::bar key should be too, since there's no or/and in opt it's a bit tricky I think.

I guess i ll split that in multiple s/keys

I don't think you can do all — yes.

That's what I'd do. ☺️

not sure why and/or is not supported in s/keys :opt, it would be useful

@alexmiller might know 🙂

Why not req (or foo (and foo bar))

I'd probably replace the #(or … with another (s/keys … so you get enforcement of the values for :foo and :bar.

@alexmiller because foo is required like this

it's should be optional, but if present there should be :bar too

Ah.

@zane yep + s/merge support etc etc

I don't think merge helps at all here

But you could and a predicate that adds this constraint

it doesn't, I was mentioning it in the context of a solution with keys vs s/and + pred with contains?

Or or 2 keys specs - one with the pair, one without

that's what I am going to end up using, but I wish it was possible to use or/and in opt

Although that may not be very useful

Opt is all optional - it doesn't make sense to have and/or there

well it'd make this example way nicer at least, there are other situations like this where it would make sense

Note that this is or, not xor

to take the other example mentioned earlier: an option map that could have credentials (optionally), but if ::user is there there must be ::password too.

user=> (s/conform :clojure.core.specs/defn-args '(foo [{x :y}])) {:bs [:arity-1 {:args {:args [[:map {x :y}]]}}], :name foo}

user=> (s/conform :clojure.core.specs/defn-args '(foo [{x y}])) {:bs [:arity-1 {:args {:args [[:seq {:elems [[:seq {:elems [[:sym x] [:sym y]]}]]}]]}}], :name foo}

@alexmiller ^ is that a bug?

Is what a bug?

sorry, should have elaborated

the second evaluation returns {x y} with a :seq node instead of a :map node

Maybe?

glad i’m not the only one who couldn’t instantly puzzle out the destructuring specs 😉

Not at a computer so hard for me to look at stuff

no worries - i’ll look at it a bit more and maybe file a bug - thanks

I guess the question is whether regex specs like cat should or do work on maps

What's the recommended way to handle specs that are dependent on runtime values?

If so, then seq-binding-form will happen to be satisfied by the map

@zane don't?

Or dynamically generate a spec

ok - i’m reasonably sure that is a bug & that the fix is a simple s/spec - making a patch

the spec splicing behavior is simultaneously useful and annoyingly subtle 🙂

Yep

decided to add a s/and vector? instead, since that seemed more reliable & more accurately spec'd (i think) - if not, happy to tweak

clj-2055