it’s a little subtle to see just from a commit, but Rich dropped a really nifty feature today - implement protocols per instance via metadata

is specify and specify! next? is this a rare case of a cljs feature going back to clj?

I don’t think so :)

in time for 1.10 or next cycle?

it’s in master now

so 1.10

isn't that going to slow down dispatch quite a bit?

just adds a check for meta in the existing path

it will completely break your satisfies? patch though :)

yeah

user=> (defprotocol P (report [x]))
P
user=> (report (with-meta [1 2 3] {`report (constantly "yo")}))
"yo"

I couldn't remember which ticket this code path reminded me of, satisfies was the one :)

yeah this is cool

direct impls still checked first so those should be unchanged

uh, that seems a bit weird to me

user=> (defprotocol P (f [_]))
P
user=> (defrecord T [] P (f [_] 1))
user.T
user=> (defrecord Y [])
user.Y
user=> (f (T.))
1
user=> (f (with-meta (T.) {`f (fn [_] 2)}))
1
user=> (f (with-meta (Y.) {`f (fn [_] 2)}))
2
user=> (extend-type Y P (f [_] 3))
nil
user=> (f (Y.))
3
user=> (f (with-meta (Y.) {`f (fn [_] 2)}))
2

the difference is a bit surprising to me

I guess it's a compromise for performance?

yeah

makes sense

well, not compromise as much as - direct impl should always win for perf

so more goal than compromise

ok

also, you might notice that symbol can now take a var or a keyword … and tehre was much rejoicing

user=> (symbol #'+)
clojure.core/+

:) yay

I added the guts in var during my error work as a half-way point and Rich picked it up here :)

no more need for .sym!

I thought you in particular would enjoy this :)

Nice! I can simplify some (symbol (name x)) calls since symbol accepts a keyword now 🙂

Tinkering about spec’ing stuff in clojure.set and the perennial question comes about: Would one accept a patch for the functions in clojure.set that coerces args to be set? The reason I’m bringing this up now is that AFAIU, the reason for not doing this previously is that the coercion has been considered expensive. but with https://dev.clojure.org/jira/browse/CLJ-2362 set should be a basically a noop if the arg is a set?

A simple no is a great answer 🙂

don’t know. certainly code exists that does not meet that and I would be loathe to break it.

Hmm, my suggestion is to patch the functions in clojure.set so they start out by calling set on their args.

well, that would break existing code

sorry, not thinking straight

you’re talking coercion not checking so I guess that would potentially be ok

Would that break the code Andy is talking about here https://clojurians.slack.com/archives/C1B1BB2Q3/p1541105759134900 ?

Coercing arguments to sets would ensure those functions always returned sets -- but there may well be code out there depending on getting non-sets back perhaps? (and, yes, you could easily argue such code is "broken" already)

I’d argue expecting non-sets back is broken

I wonder how much code out there is "broken" on those grounds? 🙂