Fork me on GitHub

will do -- I have a dirty fix to VarExpr in the compiler, but a better fix is like bronsa says to remove the :tag typehints in core and adjust the arglists hints


if it's a type hint thing and all that's needed is to change the wrong ones I could do that (if no one wants to, that's it); if it's fancier I'd need a hint where to look at

Alex Miller (Clojure team)20:06:51

@ghadi: it seems like generally it shouldn't be possible to break the ability to call .hashCode()

Alex Miller (Clojure team)20:06:03

however, I'd say this is not at all high on my list of things to care about


it's not just hashcode tho šŸ˜ƒ


or would hijacking the old ones in fn work better?


here's another example @alexmiller :

user=> (set! *warn-on-reflection* true)
user=> (.submit clojure.lang.Agent/soloExecutor str)
Reflection warning, elided.clj:1:1 - call to method submit on java.util.concurrent.ExecutorService can't be resolved (argument types: java.lang.String).
#object[java.util.concurrent.FutureTask 0x4b10966e "[email protected]"]


that reflects because the compiler things str is a String and not a callable


actually it would reflect anyways because it doesn't know that a fn var deref is Callable -- but you see the gist of the type inference problem


I could probably think of a more problematic example.


like choosing the wrong method when java arguments are type overloaded

Alex Miller (Clojure team)20:06:50

so the .hashcode thing is uninteresting except as a symptom. If you want to improve one of those tickets, maybe the older one is better, that's where I would start.

Alex Miller (Clojure team)20:06:31

why did you say it would be better to adjust the :tag / typehints? seems like that's hiding the problem, unless you're saying that the code is actually wrong.


@alexmiller: yes that'd be indeed hiding the problem, but the problem is not solvable w/o breaking existing semantics

Alex Miller (Clojure team)21:06:57

well then maybe we shouldn't solve it :)


maybe we shouldn't šŸ˜ƒ


people forget that's a defensible position


well, ret value type hints on a defn Var have been unofficialy deprecated for a while.. I wouldn't mind replacing all those instances in clojure.core with type hints on the argvec and printing a deprecation warning on old instances of type hints

Alex Miller (Clojure team)21:06:44

I'd be fine with having a ticket like that (but without the patch on core as that is not worth maintaining) for Rich to look at

Alex Miller (Clojure team)21:06:13

@dajjedzenie: sorry for ignoring you earlier, was trying to understand the problem


got it, np šŸ™‚


Why have the var type hints been deprecated?


Iā€™m still doing that to avoid having to use fully qualified type hints on the arg vec, although IIRC that might have been fixed in 1.8?