Fogus has been working through the spec-related updates for the change in 1.11.0-alpha1 to support a trailing map in calls to kwarg functions (typically spec’ed with keys* specs). This was not something we were that worried about initially, but it has turned out to be a far more intricate puzzle than we imagined.
For example, you might have a function and a spec:
;; opts can be kwarg :a or :b
(defn config [name & opts] ...)
;; (config "a-name" :a 100 :b 200)
;; spec options with keys*
(s/def ::a int?)
(s/def ::b int?)
(s/fdef config
:args (s/cat :name string? :opts (s/keys* :opt-un [::a ::b])))
;; now a valid call, but fails the spec when instrumented
(stest/instrument `config)
(config "a-name" {:a 100 :b 200})
Execution error - invalid arguments to user/config at (REPL:1).
{:a 100, :b 200} - failed: keyword? at: [:opts :clojure.spec.alpha/k]
The initial thought was just to make keys* spec smarter, but really on close examination this is problematic. keys* can be used in multiple contexts - in a custom data structure with its own syntax, in macro definitions, or in function definitions. In the first couple cases, this is effectively language created by a designer and adding newly allowed cases is probably wrong (some good examples can be built from the ns
specs). On the other side, we could leave keys* alone and add a new spec that you could "opt into" when you want this (but then everyone has to update their function specs). But we’re trying to find a middle path by hooking instrument for functions to transform the input before it is checked with keys*, so that particular case continues to work automatically in 1.11 with existing specs (and other uses are not affected). Anyhow, that work is getting close.
I’ve been working on several things, but one ongoing thing we’re exploring is some way to surface some of the static methods in java.lang.Math etc so that they are both fast and more "visible". At the moment I’m going down the path of generating a namespace by reflecting Math - originally as a dynamic thing, now looking more at code gen pre build. Still not sure exactly where this will end up. I also spent a lot of time in the last couple weeks diving into a new batch of jiras and each of those is its own little world and I will talk more about some of those as they move through the pipeline.