How to detect/avoid type piracy?

Base has only 2 methods for split, the first argument of which is an AbstractString, which don’t overlap with either of the conflicting methods; neither act of type piracy alone seemed to break anything, which suggests assumptions of whether certain split methods exist or not don’t come up often if at all. Neither OP nor the contributor to Lazy.jl knew the other planned to commit type piracy, so they couldn’t have known how to entirely avoid all conflicts with each other. In this case it’s impossible because the inputs for splitting by last indices could easily split by delimiting element instead e.g. split([1, [2], 3], [2]).

For splitting by delimiting element, the only sensible change would be to match the types split(::Vector{T}, ::T), but that doesn’t stop T == Any and forces you to convert inputs to the same type instead of allowing comparisons like 3.0 == 3. There’s not really much to improve on the method signature.

The only way to completely prevent such unpredictable conflicts among libraries is for them to not commit type piracy in the first place, contribute to the original library where agreements are made and tests can be designed.

3 Likes