This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-16
Channels
- # aws (17)
- # babashka (2)
- # beginners (131)
- # bristol-clojurians (1)
- # calva (16)
- # chlorine-clover (6)
- # cider (10)
- # clara (5)
- # cljsrn (82)
- # clojure (176)
- # clojure-dev (14)
- # clojure-europe (13)
- # clojure-italy (13)
- # clojure-nl (4)
- # clojure-spec (10)
- # clojure-sweden (32)
- # clojure-uk (32)
- # clojuredesign-podcast (2)
- # clojurescript (34)
- # community-development (2)
- # conjure (17)
- # cursive (4)
- # datomic (51)
- # emacs (6)
- # figwheel-main (26)
- # fulcro (16)
- # graalvm (11)
- # jobs (2)
- # jobs-discuss (30)
- # kaocha (4)
- # meander (23)
- # off-topic (34)
- # pathom (5)
- # re-frame (10)
- # reagent (3)
- # reitit (6)
- # releases (3)
- # sci (36)
- # shadow-cljs (27)
- # sql (9)
- # testing (6)
- # tools-deps (28)
- # vim (8)
Are there some cases where the generator override passed to st/check
will not actually be the generator used? I seem to be hitting a case like this. I do see this note in the docstring for s/gen
"Note that parent generator (in the spec or overrides map) will supersede those of any subtrees." I'm not sure if this is relevant here. It's also not totally clear what "parent generator" means in this case.
I believe there are some cases where this doesn't work. the note is talking about recursive cases I think
iirc one common issue in this area is with aliased specs