I have removed the end of my last post, it was not constructive.
Type piracy is too serious for jokes like that (and do not execute my 1-liner overloading + - it is very good in crashing the julia instance and might harm your julia installation).
I really love julia for its openness - yes, you can redefine every function. Julia trusts its users and allows very dangerous things, in contrast e.g. to java (I have abandoned java when they barricaded access to sun.misc.unsafe). Users are considered mature and responsible by the language.
Type piracy introducing new methods for existing types of other packages is dangerous. Type piracy redefining methods in other packages breaks code.
Concerning safe use of @pure, I assumed calling methods in @pure functions is safe, as long as these methods are never redefined. My example was +(Int,Int) - a very basic method on which almost all packages rely, e.g. by use of iterators over Array-s. max and abs comes next - also extremely widespread use, redefinition for primitive types very very unlikely. I would agree that the other method calls found in @pure annotated julia Base functions are also very unlikely to be redefined. If my assumption is correct, it justifies use of @pure in julia Base.
But it is very likely that method tables of these widespread functions like +, max, abs are changed by user packages. Does @pure induce risks only in type piracy cases, or also on “legal” enhancements? Some pseudocode to clarify:
module Base
abstract type AT1 end
const CT1 = someConcreteSubtypeOfAT1()
f(x::T) where T <: AT1 = EXPR1
end
module MyModule
@pure function g()
local x::Base.CT1
somecodeblock()
Base.f(x)
somemorecode()
end
end
module ThirdParty
abstract type AT2 end
Base.f(x::T) where T<:AT2 = EXPR2
end
module TypePiracy
Base.f(x::Base.CT1) = EXPR3
end
According to your argumentation, f gets (probably) ill-defined if module TypePiracy is loaded after MyModule:some code portions use the redefined method in TypePiracy, some the original Base version.
Loading module ThirdParty changes the method table of f, it adds new entries. The compiler walk through the method table when looking for f(::CT1) might change, but the result of the lookup is unchanged. If @pure in MyModule caused keeping pointers to f(::CT1), they are still valid. No risk induced.
Loading module TypePiracy will replace an entry of f’s method table. If @pure in MyModule caused keeping unsafe pointers to the old method from Base, they get invalid. If julia runtime decides to carbage collect the old method code, using such a pointer might crash the machine. High risk induced.
Is this the risk scenario of @pure? If all agree on it, we could refine the @pure doc and get rid off the current unsatisfactory situation, where the doc classifies almost any practical use of @pure as incorrect.