cljs.core/test doesn’t seem to find the :test function in metadata:

$ clj
Clojure 1.9.0
user=> (defn ^{:test #(assert false)} foo [] nil)
#'user/foo
user=> (test #'foo)
AssertionError Assert failed: false  user/fn--145 (NO_SOURCE_FILE:1)
user=> ^D

$ clj -m cljs.main -r
ClojureScript 1.10.439
cljs.user=> (defn ^{:test #(assert false)} foo [] nil)
#'cljs.user/foo
cljs.user=> (test #'foo)
:no-test
cljs.user=> ^D

$ planck
ClojureScript 1.10.439
cljs.user=> (defn ^{:test #(assert false)} foo [] nil)
#object[Function]
cljs.user=> (test #'foo)
:no-test
cljs.user=>

@shaunlebron My guess would be that because it existed before the rudimentary support for vars was added, so instead you pass the function value

Maybe things could be revised

@mfikes ah, you’re right, thanks:

$ clj -m cljs.main -r
ClojureScript 1.10.439
cljs.user=> (defn ^{:test #(assert false)} foo [] nil)
#'cljs.user/foo
cljs.user=> (test foo)
Error: Assert failed: false
cljs.user=>

Maybe worth a JIRA to see if we can clean it up a bit

i’ll file and post here

submitted issue with working patch: https://dev.clojure.org/jira/browse/CLJS-2978

I hope people don't mind another question about analyzer behavior. When analyzing specter the analyzer is throwing an Unable to resolve var: coll? in this context at line 1449. coll? being a built in I'm unsure how this is possible? (link to code in thread)

Found a discrepancy between clj + cljs:

(subs "" 1) ;; throws in clj
(subs "" 1) => "" ;; in cljs

(subs "" :a :b)

I want to say that all are undefined behavior. (Also, any attempt to do anything about it messes up the “optimized for correct programs” theme.)

@mfikes I think I’ll need to make a special case for the subs spec in cljs then, because currently re-seq runs into trouble with it

Maybe re-seq could be revisited if it is relying on undefined behavior?

good point

I’ll make an issue for it

Really, if we absolutely need to, re-seq could call .substring directly, which is a little gross. But, arguably if it is relying on JavaScript semantics for some reason, maybe it shouldn’t be calling subs

Issue with patch: https://dev.clojure.org/jira/browse/CLJS-2979

Huh, looking at the source for re-seq I think I also see an opportunity for improving performance: it's searching the string twice by running .search to find the index after running re-find. re-find already uses re.exec to find the match, it's just discarding the index you get from .exec. It could skip having to search the string twice by calling .exec directly.

what’s the maximum ecmascript standard that cljs wants to support? specifically, is it ok to rely on the .-index property in the array resulting from a call with (.exec #"a" "a").

@jesse.wertheim points out it dates back to at least 1999 (link: https://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf). if we could use this in re-seq, it could be further optimized.

We’ve been targeting ES3 (https://clojurescript.org/guides/faq-js#does-clojurescript-work-in-old-browsers)

should be good then

@jesse.wertheim issue updated with your perf suggestion: https://dev.clojure.org/jira/browse/CLJS-2979

@jesse.wertheim it seems to help a little bit:

cljs.user=> (simple-benchmark [re #"\d+" s "a1b22c333d"] (re-seq re s) 100000000)
[re #"\d+" s "a1b22c333d"], (re-seq re s), 100000000 runs, 50975 msecs
nil
cljs.user=> (simple-benchmark [re #"\d+" s "a1b22c333d"] (cljs.core/re-seq re s) 100000000)
[re #"\d+" s "a1b22c333d"], (cljs.core/re-seq re s), 100000000 runs, 53529 msecs

for longer strings, the difference may become more significant

yeah - I imagine with direct benchmarking the JS jit engine might be able to optimize things a bit to reduce the difference, but that might vary in the context of a full application as it prioritizes what to optimize

but to your point it could make for a big difference for longer strings, which are going to be a good usecase for re-seq

I imagine that a global JS regex might be faster since you can just keep calling exec and look at the lastIndex property of the global regex, but it probably would lose out since you have to do something nasty under the hood like (RegExp. (.-source original-re) "g") and dynamically rebuilding the regex using the constructor would be expensive

correction: converting to a JS global RegExp would prevent needing to use subs at all (unless you wanted to include it in the result), since each exec gives you the matches, but it would probably only really win for long strings because of the cost of using the RegExp constructor