Because?

Hunch is that this messes with chunking (`even?` is applied to a huge chunk). https://github.com/clojure/clojure/blob/e6fce5a42ba78fadcde00186c0b0c3cd00f45435/src/jvm/clojure/lang/LongRange.java#L120

(count (chunk-first (range 100000000))) is 100000000

In 1.11.1 this would be 32 and laziness would be preserved... while the change seems to make that expression be eager

Range never actually eagerly computed values, so nothing has changed there - it just makes one giant chunk rather than n

I did perf test the range changes in a variety of ways and it is much faster in some cases, like reduce and iteration (a wash in others)

filter is still making a chunk of 32

Ahh, perhaps this isn't the case on Clojure master? If I evaluate (take 3 (filter even? (range 100000000))) in 1.12.1-alpha1, I think I get a huge chunk being evaluated...

Here is a repro... if you evaluate (take 3 (filter (fn [x] (prn x) (even? x)) (range 100))) you will see 100 applications

I’ll take a look

Extracting a bit of the logic from filter this seems relevant: (let [r (range 100)] [(chunked-seq? r) (count (chunk-first r))]) -> [true 100]

Rich and I talked about it today, I'm going to just fall back to making 32-element chunks in range for now, will target that at alpha2

thanks for the question!