Re: clojure.spec merge+or bug?

I got bitten by this today as well... makes it hard to add a predicate that destructures the map and compares its values. On Friday, August 17, 2018 at 4:35:12 PM UTC-4, Alex Miller wrote: > > With s/and, conformed values flow through the predicates. This allows you > to take advantage of

Re: clojure.spec merge+or bug?

With s/and, conformed values flow through the predicates. This allows you to take advantage of structured values from early preds in later preds, so you're not having to re-understand the structure. (There are cases where having a non-flowing s/and would be useful and we've talked about adding

Re: clojure.spec merge+or bug?

Sorry, I meant to file a bug and even try to write a fix, but I was very pregnant at the time and then I gave birth so it sort of fell by the wayside. I'm interested in understanding why non-flowing behavior on conform is expected/desired behavior. I've found that when clojure design decisions go

Re: clojure.spec merge+or bug?

Thank you for explaining! Just in case, I opened a bug here https://dev.clojure.org/jira/browse/CLJ-2388 On Thursday, August 16, 2018 at 6:47:30 PM UTC-7, Alex Miller wrote: > > The non-flowing behavior on conform is expected behavior. > > Failure to roundtrip conform then unform is a bug (so

Re: clojure.spec merge+or bug?

The non-flowing behavior on conform is expected behavior. Failure to roundtrip conform then unform is a bug (so I'd so the bug here is in unform). On a quick search, I don't believe this was filed, but I could have missed it. On Thursday, August 16, 2018 at 8:28:54 PM UTC-5,

Re: clojure.spec merge+or bug?

Achhh, just spent the last few hours fighting this unexpected behavior with s/merge, until I finally came to realize that this is what it was.. I see this thread is quite old, did anyone open a bug for it as mentioned above? @Alex, you said this was the expected behavior, but then asked to

Re: clojure.spec merge+or bug?

You can file a bug on the s/merge unform - anything that doesn't roundtrip should be a bug. On the coll-of one, I thought that was just fixed in the latest spec.alpha release (see https://dev.clojure.org/jira/browse/CLJ-2076) - are you using latest there? -- You received this message because

Re: clojure.spec merge+or bug?

It also seems to come up with coll-of + or: user> (s/def ::a (s/or :even even? :odd odd?)) user> (s/def ::c (s/coll-of ::a)) user> (s/conform ::c [1 2 3 4]) [[:odd 1] [:even 2] [:odd 3] [:even 4]] user> (s/unform ::c (s/conform ::c [1 2 3 4])) [[:odd 1] [:even 2] [:odd 3] [:even 4]] It looks

Re: clojure.spec merge+or bug?

thanks for the fast reply! do you think it will always be this way? it does seem to violate the expected conform/unform relationship. On Wed, May 31, 2017 at 9:51 PM, Alex Miller wrote: > This is actually the expected result. s/merge doesn't flow like s/and - > only the

clojure.spec merge+or bug?

This is actually the expected result. s/merge doesn't flow like s/and - only the conformed version of the last map spec in the merge is used. There are thus some unexpected results in combination with the -un options as they are the only link towards conforming. One thing you could try instead

Re: clojure.spec merge+or bug?

PS - I just realize I wasn't using the latest version of spec, as is evident from my require, but I just tried again with the latest and it doesn't change the result. And I should have mentioned that I'm happy to take a stab at a fix, assuming I'm correct that this is a bug. -- You received

clojure.spec merge+or bug?

I think I found a bug in spec when combining merge and or. Basically, when you conform a map where one of the keys has an or, and the spec comes from a clojure.spec/merge, one of the underlying keys will conform it, while the others don't, and then when the results get merged together you can