@hiredman yea, that makes sense. unfortunately wasn't my problem but i figured it out anyway (something unrelated)

the error message i was getting from spec was unintelligible but i just massaged the code, fixed any issues i saw via manual inspection and it eventually went away

narrowed it down to instrument actually doing more than I figured it would. looks like it exercises the instrumented with some values that the user itself isn't passing in. this was a bit surprising to say the least

kept trying to find where the ((nil)) value was coming from in my code/ how that was even possible etc etc

@johanatan If you instrument a higher-order function -- one that takes a function as an argument -- then it will use generative testing, as I understand it.

with coll-of, is there a way to say: this collection ca be empty, but it can't be nil i.e. [] is okay, but nil is NOT okay

hey all. Is there a spec for something I can use as a predicate for s/valid?

I want a spec that matches both predicate functions and the names of specs.

@qqq it works like this by default

(s/valid? (s/coll-of any?) nil) returns false

@mpenet: yeah, thanks, I should have run that test, turns out bug was elsewhere and I was misattributing it

@seancorfield it was a higher-order function in this case. any idea the reasoning behind using generative testing for this case? is it just a 'hack' since the function inputs cannot be inspected to a level of detail necessary for verification?

I thought that was explained in the Spec Guide on the web site @johanatan? I certainly wouldn't say it was a 'hack'. It seems perfectly reasonable to me. How else would you verify that a function you're passing as an argument conforms to its spec in this situation?

It s doable at invoke time

There is/was a ticket about this

I personally wished it was like this, now I almost always spec hof as ifn? for instrumentation because of this, which makes it a bit useless

Imho both make sense in some cases, we should just have the choice

It was clj-1936 not sure if there is a new ticket started from the discussion there

@seancorfield it probably is explained but i haven't read the guide from beginning to end so could've missed it. well, yea, in a dynamic language this probably can't be done (except perhaps by inserting metadata onto anonymous functions at their definition sites and then reading it back out at the spec check sites [which now that I mention it, does sound like a better way if it would be possible to impl])

[but by 'hack' i meant, an unfortunate edge where the abstraction leaks due to limitations of the underlying system being modified]

@triss isn't spec? what you are asking for?

@johanatan Not quite.

I’m validating on (s/or :fn fn? :keyword keyword? :spec s/spec?) is there a neater way?

I'm starting to love spec's dynamic attributes.

I'm doing some GUI layout, and I can write a spec of :assert that the sum of the width of the elemes of this vector is <= width of the screen

hit is nearly impossible to do in static type systems

@triss Do you want to validate that something is a registered spec or that it looks like it could be a spec?

is a registered spec would be best for me

For the former, you could use #(try (s/get-spec %) true (catch Exception _))

That would be false for predicate functions tho'...

...but it would validate that you actually had a named, registered spec (keyword).

ah i see. that’s a handy snippet fro something no doubt…

(so I guess you'd still want (s/or :fn fn? :spec #(try ...)) ?)

I’m gonna have to scratch my head for a bit about what I want to match on really… I want anything that woks as the first argument for s/valid?

where is the spec for s/valid?

Based on the docstring for s/valid?, it doesn't look like there's a spec registered for it.

The source shows it calls specize on its spec argument and that in turn is

(defn- specize
  ([s] (c/or (spec? s) (specize* s)))
  ([s form] (c/or (spec? s) (specize* s form))))