Fork me on GitHub

I need a way of notating the return type of a macro for inference purposes


@lilactown macros don't have a return type (usable for inference). the code they generate may have but how you annotate that depends on the code it generates


the problem I have at the moment is that I’m using type inference within a macro, but the body obviously hasn’t fully expanded yet. so I can’t infer in the case when it’s nested:

(d/div (d/div "foo"))
the first d/div macro will expand, and try and infer the type (d/div "foo") which will come back as any Once it expands, the code it generates is annotated with the correct type


(extend-type com.cognitect.transit.types/UUID cljs.core/IUUID)
with *warn-on-infer*, that code results in
Cannot infer target type in expression (. com.cognitect.transit.types/UUID -prototype)
is this a bug? I see a related issue but it is specific to extending Object -;orderby=priority%20DESC&amp;keyword=extend-type%20infer


@mhuebert I'm pretty sure there's still a round of issues around warn on infer and deftype/record


there's a bunch of other things that came up via @roman01la and the plan is to address these in the next release


@thheller re: goog.module - the docs suggest bundling now instead of individual loads? or does that still work anyway regardless of the recommendation (this would be a serious drawback IMO if not)


@mhuebert feel free to file that specific bug


@dnolen the goog.module stuff just needs pre-processing so that it actually becomes loadable. it can still be loaded using the goog debug loader though. they even have a "transpile" mode that does this on the fly in JS but I haven't used that. in shadow-cljs I just run all the goog code through :whitespace once so it rewrite goog.module to the loadable code


FWIW the rewrites it does fore goog.modules are pretty minimal

goog.loadModule(function(exports) {
  "use strict";
  const asserts = goog.require("goog.asserts");
  const reflect = goog.require("goog.reflect");


basically just wraps it in a function


one more question re: type inference. is there a correct way to notate the RHS in a let-binding? what I'm finding right now is:

(let [foo ^string (bar)]
  (ilk.core/inferred-type foo))
the ^string notation is effectively ignored. however, notating the name foo does seem to work


Are you sure it’s not an issue with ilk ? I can’t repro this using analyzer directly


I am not using ilk for my actual code


I'll see if I can create a minimal repro and put it on GitHub


I can turn all of these into JIRA tickets and poke at them in the cljs compiler, if there's not already a solution for them...


for the above - yeah make a ticket


re the macro problem - I don't know what you can about that - you have to expand


@lilactown what about a return type tag on bar?


haven’t tried it. these are macros that are emitting calls to external JS so it’s a little harder to annotate return types


specifically, I’m trying to emit something like this:

(useMemo #(str "a" "b"))
and in my macro, annotate the expression with the same type as the function passed into it


(`useMemo` does some stuff under the hood but essentially will always return the same type as the function passed into it)