I feel like there's a missing flag on s/keys, something like 'complete' or {:allow-unspecified false} as an option. A couple of times while using s/check i've spelled something wrong, in the spec, or set a key badly in the transform code, and spec isn't yelling at me about it, despite everything being spec'd up, it comes down to this for me:

(s/def ::key integer?)
(s/def ::other integer?)

(s/def ::map
  (s/keys :req [::key]
          :opt [::other]))

(s/valid? ::map {::key 1 ::others "2"}) => true

(s/def ::map
  (s/keys :req [::key]
          :opt [::other]
          :complete true))

hopefully someones going to tell me it already exists somewhere now!

The usual workaround is to combine the s/keys spec with an s/map-of spec

(I agree that a :complete flag would be a welcome addition to the s/keys macro, but Rich seems committed to open maps as the preferred general data structure)

specs always make positive statements about data, not negative ones and we do not plan to add anything to s/keys along these lines

however there is something we’re considering that would allow making these additional assertions easier

@donaldball that does work, but is pretty ugly isn't it. Sound like a 'wait and see' situation

It’s not a hard macro to write, a keys variant that allows a complete? flag

yeah i just started bashing it out 🙂

{:clojure.spec/problems
  [{:path [:args :idx],
    :pred :clojure.spec/unknown,

can anyone point me in the direction of tracking down why that's unknown?

I get a caller, but I go to that line, and it's downstream from the function that :sym references :thinking_face:

so I must be misunderstanding something fundamental

the fact that it’s printing unknown there is a known issue with describing preds

so that part is a known bug

but you have the path so it should be pretty narrowly scoped to where the pred is failing?

ok, that helps, so go through and perhaps exercise my specs to see if anything's funny?

I'm probably doing this the worst way, by trying to migrate from schema instead of using on a fresh codebase

as with most programming things, it’s best to start small and build up

as a general comment, the jump to mandated generative testing is a bit of a leap

maybe I'm doing something wrong, but I don't always need this

with a lot of side-effects, traditional unit-testing can work just fine, and I just want to make sure functions deep in the call stack are getting the right arguments and returning something valid

my impression after a couple weeks is that spec makes this some of this more difficult over, say, schema

and maybe that's the intent: lower-level, more correct, more powerful, etc., it just also means there aren't yet companion libraries to help with the porcelain

maybe I'm just spoiled by clojure's quality... alpha is usually good enough 😄

You don’t need to buy into generative testing to use clojure.spec. instrument with traditional example-based tests is pretty useful.

@donaldball that was my early reaction as well, but I lost the ability to check return values, which I get, that's for check, but then that forces me into the generative style

happen to have a piece of code you transitioned that you're happy with?

Alas, nothing public, sorry

IIRC clojure.java.jdbc uses this to good effect tho

i also kinda wish instrument checked return values

@jrheard this thread was helpful in describing the philosophy https://groups.google.com/d/msg/clojure/JU6EmjtbRiQ/WSrueFvsBQAJ

thanks for the link, haven’t seen this

and I think I agree, I just have the same desire as this guy https://groups.google.com/forum/#!msg/clojure/RLQBFJ0vGG4/E0tHqVyQBgAJ

is there any way to view those google groups links without having a google account?

@mattly: The link works for me with no google account signed in

@mattly I brought one up in incognito

bah, ok, so it wants me to sign in with one of the google accounts I'm signed in as

which doesn't work because I signed into my google accounts in the wrong order

...sorry, wrong place for this rant

I use chrome profiles, separate windows, yada yada

(s/def ::select
  (s/coll-of (s/or :attribute string?
                   :subselect (s/every-kv string? ::select :count 1))))
(clojure.pprint/pprint
 (s/conform ::select
            ["1"
             {"2" ["2.1"
                   {"2.2" ["2.2.1"]}]}]))
;; => [[:attribute "1"] [:subselect {"2" ["2.1" {"2.2" ["2.2.1"]}]}]]

You need conform-keys

Hmm, :conform-keys is only listed as an option for map-of but I would expect it to work here too...

Why would I need conform keys? "2.1" is being conformed by the s/or.

It's like conforming stops at the recursive step.

Nope, only works with map-of — but if you change :subselect to be (s/map-of string? ::select :count 1 :conform-keys true) then you get this

[[:attribute "1"]
 [:subselect
  {"2"
   [[:attribute "2.1"] [:subselect {"2.2" [[:attribute “2.2.1”]]}]]}]]

I still don't understand why :conform-keys has anything to do with this.

It's the values that need conforming.

Yeah, I think I misunderstood what you were saying didn’t work..

Is the output I got with map-of what you want?

I would just expect that in my original example "2.1" would be [:attribute "2.1"].

Why is the recursive s/or not being conformed?

(You’re right, you don’t need :conform-keys but you do need map-of, not every-kv)

It seems like it happens, but only sometimes.

Per the docs, every-kv does not conform all values — map-of does.

"Unlike 'every-kv', map-of will exhaustively conform every value."

Ahhh.

I missed that in the docs.

"Note that 'every' does not do exhaustive checking, rather it samples coll-check-limit elements. Nor (as a result) does it do any conforming of elements.” — and every-kv is like every

Got it.

Phew. Thanks, Sean.

(I must admit, I find it counter-intuitive that every / every-kv do not in fact check every element but coll-of / map-of do)

After all, they have every in their name so you’d sort of expect them to check every item...

heh yeah

it is the least-intuitive thing. I wish I understood the rationale.

It's heartening that I'm not the only one. 😅

"every" is an assertion of belief

Not a statement of what they do

^ rationale @jrheard @bhagany @zane