(Just wanted to point out this seems slightly out of sync with @mbauman definition above)
OK, so based on this definition, if I define + on MyNumber <: Number it is not type piracy, and if was to add in a package to extend Distributions.jl in the Distributions namespace with a function called “expectations” operating on the various types in Distributions.jl, then it would not be type piracy.
If so, then it sounds like “Type Piracy” should almost always be discouraged or treated with a great deal of caution.
So lets say that the “biggest” supertype for any method on size is Number <: Any and I define a function Base.size(x::MyType) where MyType is not a subtype of Number. then this is not type piracy (which is a good check on one of the things to discourage). In this case, while the Base may not be for type piracy, it is being done to make punning convenient. In the case of size we know it will be in Base and that using Base is always there (in practice), so it is easy to know where to put the method. It is not fragile to any ordering. But that is not the case of doing punning with other packages, e.g. the solve in DiffEq, where the ordering matters.
But I would still prefer to say
@merge function solve(x::MyType) or @merge size(x::MyType) = .... to merge it into the active namespace (if it exists) or the @merge using MyPackage if I had my function in a package. I think it is honest on what you are doing, and makes punning a lot cleaner. Again… all of this only applies to to cases where things are not a “bad-pun”, which is why I am not suggesting things are automatic.