Gary talked about an interesting issue recently. What if you instrument all and there are loads of fdefs for core functions. This will create a lot of validation overhead. Anyone experienced this becoming an issue?

There's definitely overhead. By rights it shouldn't matter so much at dev time which is the common use case for instrumenting.

Good morning, I recently started using spec and I wanted to know the reason behind why s/and conforms values and propagates them. I hadn't read the spec guide (https://clojure.org/guides/spec#_spec_ing_functions) in full before I found the first example of this in our code base and I found it hard to read.

conforming tells you not just whether something validated (like valid? but how it validated - indicating which alternatives are taken and how value components were parsed). Flowing conformed values allows s/and to also flow conform info out to the user from internal components (which is also done in most other conforms)

Is it possible to "redirect" a failure. For example, if a list of numbers must be sequential, this validation can only be performed on the "whole", but the failure is on a particular index.

not without implementing your own spec

@alexmiller is that api private currently?

it’s public but undocumented and subject to violent change

as in, I expect it to change, and possibly even be completely replaced.

I'll wait on that, knowing it isn't impossible is good.

things like spec-tools are using it extensively

It was one frustration I'd had, e.g. for password validation data.

Yeah, I wasn't touching it because I know it will break some day.

the Spec protocol will be replaced? Is it possible to comment or discuss on the upcoming changes, from 3rd party library maintainer perspective?

no, I don’t know yet what they will be

it may be replaced, it may not be replaced, it may change, I have no idea yet

this is the alpha part of spec.alpha

my advice right now would be - don’t use that

I expect changes to the main user api of spec to be minimal or at least well thought about

ok. thanks. there is a alpha disclaimer too on spec-tools, but just checked, it has 13k downloads, so someone is using that already. hopefully there is a way to port the features to new spec apis - or remove stuff that is implemented by the new core directly.

I have not been shy about telling spec-tools and others what I said above

spec-tools is almost certain to be broken by future spec changes

I don’t agree with most of what that library is doing