1.7.0-alpha3 breakage due to symbol conflicts

OK I understand, though I think it's a poor design decision if that is the case, and will probably continue to complain whenever it breaks user code.

Ultimately, I think it is very inconvenient to push users to explicitly declare every single used var, especially in exploratory / demo code. In fact I can't think of another language off the top of my head that enforces something like this as a policy.

I'm re-closing this ticket since the snipeet you just posted demonstrating has nothing to do with the bug reported in this ticket and is actually not a bug at all but a design decision of clojure that's alwasy been this way.

Only overriding clojure.core vars will give you a warning since they are referred by default, overriding var from other namespace will and has always caused an error since you control whether to refer them or not.

:refer :all is discouraged for this reason, among others.

The simplest way that I can reproduce it is as follows:

=> (ns foo)
nil
=> (def a 1)
#'foo/a
=> (ns bar (:require [foo :refer :all]))
nil
=> (def a 2)
CompilerException java.lang.IllegalStateException: a already refers to: #'foo/a in namespace: bar, compilingNO_SOURCE_PATH:1:1)

Think of "foo" as a library namespace like "clojure.core.matrix" and "bar" as user code. I would expect user code to be able to override the var that has been referred (possibly with a configurable warning). So the scenario I am trying to avoid is user code breaking whenever I add a new var like "a" to core.matrix.

Can you add a new reproduction case? The one you previously posted (that is in the ticket description) now works.

FWIW, I think the current patch is simply too narrow in scope. We should apply the logic of not throwing an error to any var, not just core.