Make Base exports yield to package exports

[LilithHafner]

When a user uses an unqualified using statement which loads symbols that are also exported from base, I propose that the names exported from the used package take precedence over the names exported from base. The user explicitly asked for the package while they did not explicitly ask for Base, and we should prioritize what the user more explicitly asked for.

This resolves the issue where a new export from Base conflicts with an existing package export, causing breakage for folks who use unqualified using. (I find it substantially less likely for a package to add an export that is already exported by base than for base to add and export that is already exported by a package)

Current

julia> module Distances
       export close, far
       close(x) = x < 10
       far(x) = x > 100
       end
Main.Distances

julia> using .Distances

julia> close(5)
WARNING: both Distances and Base export "close"; uses of it in module Main must be qualified
ERROR: UndefVarError: `close` not defined
Stacktrace:
 [1] top-level scope
   @ REPL[43]:1

Proposed

julia> module Distances
       export close, far
       close(x) = x < 10
       far(x) = x > 100
       end
Main.Distances

julia> using .Distances

julia> close(5)
true

This would not effect package-package conflicts. I think this proposal is worth implementing regardless of the outcome of #42080, #53428, and friends because there will always be some users of unqualified using and this proposal will only effect those users (and I believe effect most of them positively).

[KristofferC]

This would mean that working code would suddenly become nonsense if a used package did in fact add a a name that the code originally was using from Base? At best you get an error at worst your password check is disabled?

[mbauman]

Right, this would also allow packages to intentionally coopt some names (and some syntaxes) more seamlessly:

julia> module Derivatives
       export var"'"
       var"'"(::typeof(sin)) = cos
       var"'"(::typeof(cos)) = (-)∘(sin)
       end
Main.Derivatives

julia> using .Derivatives

julia> sin'(pi)
-1.0

This is something I'm certain some packages would want to do — but having an existing package introduce such an export with this behavior would be so terribly fraught for existing codebases.

[adienes]

I would have to say I don't think a change like this moves Julia in the direction of being "easier to reason about, less bug-prone, regression-free"

[LilithHafner]

I agree with all of the above. Apparently I didn't think this one through all the way :)