This looks nice, I'll have a closer look over the next weeks to see if it makes sense for the issues addressed by it to be solved in Ghostwheel – and if so, talk to @U0CKQ19AQ about merging the projects back together – or if it's better for them to continue separately.

I think the major conflict point is around the testing features, guardrails made de design decision to don't have any of it

impl details I think is a bit different too, guardrails just injects validation code in the fns, while gw I guess uses the instrumentation stuff from spec (for instrument at least, but I may be wrong here, you know better :))

Thanks for the pointer and you're correct regarding Ghostwheel using the spec instrumentation stuff. :) I have absolutely no problem with a fork that goes in a different direction, I'd just like to minimise the duplication of effort, whatever a possible solution to that may look like. If it turns out that a merge does not make sense and/or is not desired by either party for whatever reason, we could for example extract the gspec parsing functionality into a separate shared library so that both Guardrails and Ghostwheel benefit from improvements / fixes in that area. I have to get back up to speed with my code/notes/release status and look at Tony Kay's feedback and changes to get a better picture of where I see things going and then we'll take it from there.

Either way, I'm happy that Guardrails has embraced the gspec syntax, because I'd really like to see that become more common throughout Clojure code bases everywhere, whatever the underlying tooling does with the information in terms of instrumentation/testing/type-completion, etc.

I really like the syntax too, and there are other things I miss on guardrails that may be added, like a way to annotate annonymous fns, eg: (>fn [foo bar] [int? string? => string?] ...)