Switch clj-nil to not be considered a numeric type

Question

We should be able to get a warning like


cljs.user=> (+ nil 1)
WARNING: cljs.core/+, all arguments must be numbers, got [clj-nil number] instead at line 1 <cljs repl>
1


We'd first need to fix CLJS-3085.

But with that, it seems as simple as having {{cljs.analyzer/numeric-type?}} return {{false}} instead of {{true}} for {{'clj-nil}} by deleting the {{cond}} branch for it.

Answer 1

Comment made by: roman01la

Submitted a patch with a test case.

Answer 2

Comment made by: mfikes

When applied with CLJS-3085:

CLJS-3086.patch passes CI and Canary (/)

CLJS-3086.patch added to Patch Tender (i)

Answer 3

Comment made by: mfikes

Hey Roman,

Here is an interesting bit of code to ponder in the std library that this patch triggers a warning for

https://github.com/clojure/clojurescript/blob/c87d61e54fbbeae390e522ba315f0207fb0fed75/src/main/cljs/cljs/spec/alpha.cljc#L264

`
cljs.user=> (s/coll-of any? :kind any? :min-count 1)
WARNING: cljs.core/+, all arguments must be numbers, got [clj-nil number] instead at line 1
WARNING: cljs.core/+, all arguments must be numbers, got [clj-nil number] instead at line 1

object[cljs.spec.alpha.t_cljs$spec$alpha23729]

`

I haven't thought about it in too much detail yet, but it raises a good philosophical question where if you have code like the following, is there a type error?

(if nil (+ nil 1) 0)

My initial hunch is that while this is a tree falling in the forest that we might be able to address somehow, maybe instead the offending macro can be corrected. Anyway, didn't want to yet spend a lot of time dwelling on it and wanted to at least share it with you.

Answer 4

Comment made by: mfikes

Independent of this ticket, we have some precedent: This triggers a diagnostic in 1.10.520:

`
cljs.user=> (when false (inc false))

                    ^

WARNING: cljs.core/+, all arguments must be numbers, got [boolean number] instead at line 1
nil
`

Answer 5

Comment made by: mfikes

It's my opinion that the macro should be fixed. The above shows that, even though you could statically prove that a certain code path isn't taken, analysis warnings trigger for code on that path.

Answer 6

Reference: https://clojure.atlassian.net/browse/CLJS-3086 (reported by mfikes)