Interesting view regarding type inference and compiler perf: The primary purpose of types (hinted or inferred) in ClojureScript is so that the compiler can leverage types to generate optimal code. While static type checking during dev is of secondary interest, a fundamental problem is that, as you add stronger type inference, you end up with compiled code that needs to be invalidated because types changed due to dynamic re-definition at the REPL. (This is similar to how premature static arity dispatch is a bad thing in the REPL and :static-fns is disabled.) Many of the type inference tickets currently in flight are proving difficult to pull off without harming compilation performance (at least a little). So... perhaps thinking of it as a knob that you turn on, akin to :advanced, would put us down a path where the cost of type inference isn't that critical, and we could afford to consider somewhat more expensive inference algorithms that we would otherwise object to.

Reading through https://dev.clojure.org/jira/secure/attachment/18433/CLJS-2869-5.patch. Is most of the diff in there?

Or do you have a branch somewhere with a diff on github?

@john All of the diff is in the -5 patch.

That patch is in https://github.com/mfikes/clojurescript/tree/CLJS-2869

Just spitballing here, but we go so far as to make a new knob for type inference, I wonder how much Ambrose work and spec could also play into that knob...

or if, in the other direction, this new stuff could be libified... Seems pretty deep in the guts of things though.

Ahh, interesting. Cook up some ways to control various aspects

:type-inference {:internal 11, :spec :core-preds, :typed-clojure some-lib/fn}

^ Seems complicated, maybe a simpler way to convey intent

And, perhaps some ability to leverage existing specs to populate the hierarchy?