@rschmukler malli.provider, transformer, so it could if there is a use case for it. Some kind of extension mechanism would be good anyway, adding inferring to :tuple and :multi currently require a lot of internal refactoring. Not easy to add inferrers to own schemas.

as it's not complete yet, would be good to add the missing inferrers and options to controls those and see what kind of architecture evolves out of those.

maybe options like {:infer {:multi {:stats ...,. :schema ..., :opts {:dispatch #{:type 'first}, :min 2, :propability 0.90}}},

e.g. callback to participate in extracting stats out of samples, and converting those into schemas + opts for what kind of multis to look and how many samples needed

might be better to start with just options and hard-code the impl, and try to extract the callback mechanism later.

@ikitommi the other thing I was thinking about is the ability to code options. ie. imagine a LocalDateTime parser that has an property of :date/format "MM/dd/yyyy" - ideally it'd be good to specify "try these formats when you try to parse things as a date" etc

Still thinking about how it could look

idea: If the inferrer is good, there could be a tool that records all args and return values for functions and infers defn-schemas out of those. I think @ambrosebs did something similar with spec (using core.typed)

Lovely idea!

@ikitommi that's awesome. this information can then also be used to generate clj-kondo type annotations