how can I spec the return spec of a function that depends on the args it received : ex ring-spec normal handler vs async-handler: (if args.length == 3 : ret then is nil else response map)?

I guess I can hack something with :fn, but it doesn't feel right

a "multiple arity" version of fspec could make sense here. it would feel more natural maybe

(s/fspec (:args ... :ret) (:args :ret))

or maybe I can just write 2 fspec and just wrap them with (s/or ..)

You could make the ret spec nilable and describe that relationship in the :fn as you mentioned. Doesn't seem like that much of a hack to me

I think I prefer the s/or with the 2 fspecs, makes the relation between args/ret clearer

I came up with this in the end https://github.com/mpenet/ring-spec/blob/master/src/clj/qbits/ring_spec.clj#L81-L111

@mpenet: the whole purpose of :fn is to describe relationships between args and ret

got it, so not really good to discern 2 arities of a function like I was doing (I had one "giant" fspec describing both arities/return types)

seems perfectly reasonable to cover each possibility in the :ret (just tell the truth about what it can be)

then in :fn you can declare that the :ret you got matched the :args that were sent

you get conformed values of :args and :ret in :fn, so it should be relatively easy to check

Yes I saw this, but wouldn't it be more work for gen down the road having all these branches? I mean vs. (s/or (s/fspec) (s/fspec))

I guess it depends what kind of functions we re talking about

it just picks one or the other

that’s why I have a computer :)

any teaser of what's coming in the next alpha?

a fully-featured dependent type system

@gfredericks: you joke, but: https://github.com/arohner/spectrum

@arohner: oh hey good!

It still needs a whole lot of polish, but I’m convinced its sound

wow, impressive. will kick tires for sure

it’s still basically at developer preview stage

basic tests pass, and simple files will check / not-check as appropriate, but nowhere near ready for production code

@mpenet I have some of the nastier core macro specs ready and some of them might land in the near future

gfredericks: Preferred schpec namespace for maps that are closed for extension and its generators? keys?

Also, weighted-or

(weighted-or:

(defmacro weighted-or
  "Like [[s/or]], but with weights."
  [& weighted-options]
  (let [[names specs ws] (apply map vector (partition 3 weighted-options))
        sums (reductions + ws)]
    `(s/with-gen
       (s/or ~@(interleave names specs))
       (fn []
         (gen/fmap
          (fn [count#]
            (let [schema# (condp >= count# ~@(interleave sums specs))]
              (gen/generate (s/gen schema#))))
          (gen/choose 1 ~(last sums)))))))

Is there a pred for large integers?

Like biginteger or bigint