Inconsistent behavior when extending an operator without first importing it.

[GunnarFarneback]

I know that I need to explicitly import operators from Base if I want to extend them but it is confusing that if I fail to do so, it can either give a helpful error or silently make a new operator depending on whether I've previously used that particular operator.

julia> "a"*2
no method *(ASCIIString,Int64)

julia> *(a::String, b::Int) = "$a$b"
error in method definition: function Base.* must be explicitly imported to be extended

julia> +(a::String, b::Int) = "$a$b"

julia> +
Methods for generic function +
+(String,Int64) at none:1

[johnmyleswhite]

I agree. I think more warnings here is a good thing.

[StefanKarpinski]

This isn't inconsistent: you used * before adding methods to it, indicating that you meant for * to mean Base.* rather than a new local *; you didn't use + first, so there's no warning.

[pao]

Wouldn't using Base (which is implied at session startup and in most modules) indicate that you intended to bring the entire namespace into scope? Seems to me that Base should be defined such that overriding something in Base should need to be a Deliberate Action. That's of course an argument in turn for keeping Base limited in size.

[JeffBezanson]

Of course I want Base to be minimal, but there is no way to make it small enough that conflicts would never arise. I might be ok with giving Warning: x is also a name in Base when you use one of those names, but people would probably find it annoying. And it would mean that in practice you could not use one of those names, since people would want to get rid of the warnings.

[GunnarFarneback]

Maybe this doesn't have a really good solution.

I'm looking at this from the point of view of convincing colleagues that Julia is a viable alternative to Matlab in the mid to long term. At some point this will involve having them try out Julia and the cool things it can do. But I'm not looking forward to explaining the story that because they forgot to import + from Base when they tried out operator overloading for their new type they will no longer have addition available for anything else until they restart the REPL (or maybe they can, but I've failed to find out how to recover Base.+). Or why it makes a difference whether they started out the session by trying out some arithmetic. Matlab has the same kind of trap with first doing a loop over i and then continue with some complex computations, which will catch everybody at least once, but there a "clear i" sorts it out.

I agree that adding warnings is unlikely to be the answer. I have tons of Matlab functions using im as name for the input image and I would hate not being allowed to occasionally use e as a variable together with a, b, c, d, and f. In fact I rather find the warnings annoying already. For example I routinely want to change the promotion rule for Float64 and Float32 but can't do it without warning:

julia> import Base.promote_rule

julia> promote_rule(::Type{Float64}, ::Type{Float32}) = Float32
Warning: Method definition promote_rule(Type{Float64},Type{Float32}) in module Base at float.jl:82 overwritten in module Main at none:1.

To at least provide one constructive idea one possibility could be that if you make a new definition of e.g. + and then type + to see its definitions, it could mention that there's also a shadowed + in Base.

Going back to dependencies on what you have used before, I thought it would be a very nice example of Julia's capabilities to show how easy it is to change the promotion rule (bar the warning) on the fly, until I tried it out.

julia> 1.0 * 1.0f0
1.0

julia> import Base.promote_rule

julia> promote_rule(::Type{Float64}, ::Type{Float32}) = Float32
Warning: Method definition promote_rule(Type{Float64},Type{Float32}) in module Base at float.jl:82 overwritten in module Main at none:1.

julia> 1.0 * 1.0f0
1.0

julia> 1.0f0 * 1.0
1.0f0

Is this what the warning is trying to warn me about?

[johnmyleswhite]

I don't see why we can't offer a mode that turns off warnings.

I also think that it's a sign that Julia's name are not sufficiently precise if they're being overwritten incidentally. If you're defining a function called sort, why isn't Julia's sort what you want?

[JeffBezanson]

We have discussed before that operators seem to be a special case, and importall Base.Operators should be available, perhaps by default.
At this time, to change a promotion in Base like Float32+Float64, the only realistic way to do it is to edit the source and rebuild the system image (julia sysimg.jl is all it takes).

[GunnarFarneback]

Is there anything more needed than the fix of #265 to get a change of a promotion in Base to work?
This doesn't look consistent after only changing the promote_rule. As a workaround, overwriting promote (with the same definition as in Base) gets promote and promote_type back in sync.

               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.6.0-dev.1671 (2016-12-23 05:10 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 44d7677* (0 days old master)
|__/                   |  x86_64-linux-gnu

julia> promote_type(Float64, Float32)
Float64

julia> promote(1.0, 1.0f0)
(1.0,1.0)

julia> Base.promote_rule(::Type{Float64}, ::Type{Float32}) = Float32
WARNING: Method definition promote_rule(Type{Float64}, Type{Float32}) in module Base at float.jl:354 overwritten in module Main at REPL[3]:1.

julia> promote_type(Float64, Float32)
Float32

julia> promote(1.0, 1.0f0)
(1.0,1.0)

julia> function Base.promote{T,S}(x::T, y::S)
           (convert(promote_type(T,S),x), convert(promote_type(T,S),y))
       end
WARNING: Method definition promote(#T<:Any, #S<:Any) in module Base at promotion.jl:153 overwritten in module Main at REPL[6]:2.

julia> promote_type(Float64, Float32)
Float32

julia> promote(1.0, 1.0f0)
(1.0f0,1.0f0)

[GunnarFarneback]

After #21771 promotion changes do work.