@mfikes I'm thinking we should apply 2596 before releasing - I also want to take a look at 2957

Hrm. Maybe 2596 is a typo? https://dev.clojure.org/jira/browse/CLJS-2596

2956?

Ahh, right, has to be. 🙂

Yeah, that is a low-risk one to apply.

I wonder how @dnolen views core changes that come out of the attempt of spec’ing cljs itself. I’m sure there’s more that can be optimized 🙂

@mfikes ah yeah 2956

@borkdude do you mean if specs find bugs?

@dnolen well, 2956 is only relevant if you want to instrument cljs.core/=. my question is how far would cljs go to support that use case

if the changes are minor, I guess it can’t hurt

to me 2956 is just a bug

there's no reason instrumenting core should not work

ok. a fundamental problem we ran into was instrumenting cljs.core/apply. that one seems very tricky

right, less sure about that one

the reason is that spec-checking-fn uses apply on the instrumented function, so you get a loop

yes

probably have to live with that

I guess it’s ok to have that as the exception

you could probably make apply work as a special case - but I'll leave that as an exercise for someone else 🙂

@mfikes I'm thinking this two issues are pretty minor - we should probably just go

we can patch them up in a follow up release - I'm sure other things are going to crop up anyway

feel free to merge in the announce post, I'll ping the mailing lists and the channels during lunch

Ok, yeah—no matter what we do, we won’t find bugs until people start using 1.10.439

I’m AFK for lunch, but will merge the announcement post when back

@dnolen announcement post merged I

thanks!

We can find all the ancillary merges (compiler option doc updates, etc) since they are tagged—I can take care of those when back

Nice, looks good: https://clojurescript.org/news/news

Looks like the date of the post needs a tweak; will fix and merge when back

Fixed the date and merged in all the ancillary site updates for this release https://github.com/clojure/clojurescript-site/commits/master

👍:skin-tone-4:

The Graal.JS support in 1.10.439 is still compatible with the GraalVM RC9 that came out today. Hopefully we are home-free at this point.

nice

I was wondering about the new type inference. Is it able to warn on:

(defn add [a b]
  (+ a b))

(add "2" 2)

@didibus That's still an open area of research. With an experimental compiler change, we can infer function parameter types, and your example results in

cljs.user=> (add "2" 2)
WARNING: Type mismatch calling add: expected [number number], got [string number] instead at line 1 <cljs repl>

Nice!

I'm all in on this proposal. I don't really feel this conflicts with Spec at all. Even Clojure could benefit having this. Simple type checking goes a long way to improve usability. Better error messages, quicker. In ClojureScript, it also protect the user against its weaker runtime type checking, basically the automatic coercion around arithmetic.

TBH, my opinion has evolved to: We should leverage statically derivable type info to generate optimal code whenever possible. I think we can have a dynamic lispy language and eat our cake too.

Inference is even better for sure. But I feel there's a case to be made for static analysis of type hints. I mean doesn't CL support this fully, and no one complains that its made it less dynamic. Most people actually complain Clojure is less dynamic then CL because not everything can be reified due to the underlying JVM.

It's like a very dynamic, very loose version of gradual typing, but I feel it gives you like 80% of the potential bug reports that a much more complicated static type system would.

I don't expect to be type hinting everything because of this. I'd sprinkle it here and there, maybe I won't ever, but at least having core with them and inference would improve error messages. Also, the whole thing just generates warnings so

Also, might be able to derive type hints from specs in certain cases.

And we're not really introducing type semantics. Like you can define your own types. I think this is the big difference. You can say this takes a string, list, map. But it doesn't speak of the structure of the list or the map, mandatory keys, and the type of their values etc. This is still all left dynamic and for Spec to cover.

type-hinting is probably unlikely to ever be used for checking outside of numerics, specs are just better suited for this

definitely no future plans for type-hints that aren't mostly perf oriented