In cljs, identical? means js ===

It’s not really an intern vs not because js doesn’t expose any such semantics

But cljs = is more expensive in js (a fn call, typeof check, and worse) to get the right equality semantics clojure expects

In theory cljs could use type info to weaken = to identical if it can prove type of its args

Similar to the boolean hint allowing omission of truth_ calls

> It’s not really an intern vs not because js doesn’t expose any such semantics Hmm. I can't quite square this against my comment, so I'm wondering if we are talking past each other on different tangents. So, just for clarity, all I'm saying is ... At the js console: {"hello": "world"} === {"hello": "world"} is always false (all implementations I'm aware of) ("hello" + " " + "world") === "hello world" is always true (all implementations I'm aware of) The 2nd result only happens because js platforms intern strings. So, to me the semantics are exposed. In fact, so much so that they are explicitly exploited (efficiency!) by the reader conditional code fork questioned by thheller.

seems like we could then just optimize the = macro to use === whenever either of the arguments is a string

but reader conditionals are fine too

just get slowed down a lot when reading through any code with reader conditionals, having to context switch constantly is hard