I'm sure it isn't, but that is displaying as an uppercase 'N'.

just my font

Figured, but thought it was worth confirming.

This works :thinking_face:

Yeah, you don't need the . for the method value.

so the bottom example is the idiomatic way?

toUpperCase is overloaded on arity (with Locale in the one-argument case) so you need an arity hint ^[] to make it work as mapped method.

Clojure 1.12.0-alpha9
user=> (map String/toUpperCase ["hello" "world"])
Syntax error (IllegalArgumentException) compiling at (REPL:1:1).
Multiple matches for method toUpperCase in class java.lang.String, use param-tags to specify
user=> (map ^[] String/toUpperCase ["hello" "world"])
("HELLO" "WORLD")
user=>

Subject to change :)

@U064X3EF3 beta must be getting closer i'd imagine

Resolving on arity would make quite a few calls a lot cleaner, so I'd definitely be in favor of that 🙂

But could you have both (map String/toUpperCase ["hello" "world"]) and (map String/toUpperCase ["hello" "world"] [(Locale. "en") (Locale. "fr")]) without any reflection, just based on arity @U064X3EF3? I'm curious about that.

(I know you could do it with reflection)

This is an evolving area of design

But we are moving to a place that will support reflection and probably avoid reflection if arity disambiguates

Way back in the fall, there was discussion in the core team about prepending a dot for method calls

But it never made it into an alpha

@U064X3EF3 Is disambiguating based on a partial but unambiguous signature match on the table? E.g. when some method accepts (String, String) and (Number, Number) and you give it (String, unknown).

That’s actually a quirk of the reflection filtering. Not planning to fix it in 1.12 but there are a couple things in that area I would like to improve