In this example:

(.-someProp (first #js [#js {:someProp 1}]))

it is expected, not a bug

I don't think there's anything we can do here that would be idiomatic to improve anything

externs inference intentionally works through interop forms only

but ClojureScript functions can and will erase stuff because in general - you cannot infer much

thus explicit type hinting

Hmm, that's unpleasant. Makes relying on the warning pretty much useless - better to type hint every definition and CLJS form involved in interop anyway. But the analyzer could theoretically infer the tag in this case, no? Although, it would probably have to be a special case for first and all such functions...

I don't know this is not a common complaint

your example very contrived

for example this is not a problem if I'm writing ClojureScript and I'm actually using #js and goog.object

in fact I cannot really understand it

because if this was a real interop situation then I would just goog.object

Well, with goog.object nothing would be a problem indeed, but it's quite cumbersome when you have to do heavy interop. The example is a simplified version of this actual code:

(defn replace-track-source! [^js playlist track-name src]
  (loop [tracks (.-tracks playlist)]
    (when-first [^js track tracks]
      (if (= (.-name track) track-name)
        (-> (to-audio-buffer src playlist)
            (.then (fn [audio-buffer]
                     (let [audio-buffer (audio-util/normalize-volume audio-buffer)]
                       (set! track -src audio-buffer)
                       (.setBuffer track audio-buffer)
                       (.setCues track 0 (.-duration audio-buffer))
                       (.setPlayout track (doto (Playout. (.-ac playlist) audio-buffer)
                                            (.setVolumeGainLevel (.-gain track))
                                            (.setStereoPanValue (.-stereoPan track))))
                       (.calculatePeaks track (.-samplesPerPixel playlist) (.-sampleRate playlist))
                       (.adjustDuration playlist)
                       (.drawRequest playlist)))))
        (recur (next tracks))))))

With goog.object, any (.. a -b -c -d) becomes incredibly more complex. Any function call becomes much less transparent. So I don't think it's a good solution.

right so this example is easier for me to understand - less contrived 🙂

@p-himik we don't infer types of kind T<A>

that would be necessary here

because #js [cljs cljs cljs ...] is perfectly valid

Wouldn't the type of (aget #js [cljs] 0) be inferred as js? If no, than how does (aget #js [js] 0) work, if at all?

Also you say "we don't". But is it something that would be reasonable to do?

pretty sure aget is any

and no, interpreting the contents of arrays and object as ^js is not reasonable

we need inference for T<A>

but Clojure does not have type hinting pattern for this

Nah, I don't mean unconditionally interpreting as ^js. I did indeed mean inference.

Clojure doesn't support hinting of T<A> because of JVM type erasure

so there's not an attractive syntactical path

And I assume you don't want to have special cases for first, second, aget, etc?

absolutely not

OK, I'm just probing the ground here because I would definitely like to have a solution to that. Anything that doesn't require me or anybody else to get burned after a production release or to have an :advanced build just for that extra check of every related functionality. Are there any reasonably frequent instances where you would actually want to do JS interop on CLJS data? Maybe an extra [opt-in] warning about dot forms where the tag of the target is clj-any would be a solution?

@p-himik internally JS interop on CLJS data is how the data structures work

Well, that's from cljs.core or something like that I presume, so that's a special case. After all, you get a lot of Cannot infer target type warnings from that NS.

@p-himik or any other library that does this, which after 11 years is going to be more than you think

Alright, then remove [] around the "opt-in" part. :)

anyways just not interested in doing anything quickly here

we do index all externs, but I think our checking of deftype is not so good

probably the right way to get warning would be to check that property exists at all somewhere

a patch that does what would be interesting

because then if you can't find it - you can warn - and you can re-hint ^js

unfortunately I think it's not as simple as it sounds

one of the biggest problems with externs-inference was just having to suppress stuff deftype/defrecord

because that just wasn't relevant work at the time

Oh, I'm not talking about "do it now", of course not. If that's something that's reasonable, I might even fiddle around and come up with a patch for that opt-in warning - I just don't want to waste time if that's something that isn't worth doing at all. Also, I'm not sure whether it's the CLJS compiler that does that, but shadow-cljs documents :infer-externs :auto - it makes externs-related warnings to appear only for your own files, which is quite handy. Detection of existing properties would be quite tricky and full of false negatives. I see a lot of code where new properties are created by using string concatenation.

string concatenation of properties in cljs.core ?

I don't follow

Google Closure included all externs already - we index the all

the only that's left is correct collection of cljs.core properties - to know which ones exist

ah yes

because I added Google Closure namespace parsing

No, not in cljs.core - in JS files that I use with CLJS, the sole reason I need so much interop.

those properties absolutely don't matter

because if it's not indexed then it must be external

what I'm saying is

ClojureScript is close to indexing all properties for anything to be compiled

regardless of CLJS or GCL

thus you can know if some property is external

I'm only talking about stuff like (.-foo ...)

Ah, so in "probably the right way to get warning would be to check that property exists at all somewhere" you meant the "Cannot infer target type" warning and not the opt-in warning that I suggested? So in your example with (.-foo ...) if that -foo is something that is indexed from CLJS or GCL, then there would be no warning, it would be considered an internal property that can be minified. And if it cannot be found, then it would be considered external and the warning would be issued? What about situations where -foo exists both in CLJS/GCL and in some JS file where it's not supposed to be renamed? A user should definitely be warned in such a case as well, but I'm not sure whether it's feasible.

in CLJS and GCL -foo is not a thing really - Type.foo

so it's possible that we could use that approach

at least for internal data structures I don't think this will be problem because it's written in such a low level way - either the type is know or could be trivial hinted

though now that you bring it up - the main issue if perfectly legitimate non-interop (deftype) code in some library

that does (.-foo (first ...)

because again we don't know about T<A>

Right. So at least to me (a layman when it comes to compilers, really) that opt-in warning about constructs like (.-foo (first ...)) stills sounds like a reasonable solution.

it's worth opening a JIRA ticket about the basic problem - stuff like this usually take some time to really think through all the options

I don't have access right now but I can write the initial version of the issue description if that's helpful.

@p-himik happy to paste it in if you drop a link to a gist or something

You can always add it to ask Clojure too