this is not the only situation that can change what methods get called given the same set of arguments. A package could have a generic fallback on abstract types, then another package / user come along added a subtype of that abstract type and added a more specific method.
2 Likes
Yes, I’m aware. If you’re not overwriting the method, I’m saying that the more specific method should be ignored when called from inside a pure function if it’s not pure. This strikes me as a good thing – if a more specific method is impure while the more general method is pure, they’re probably doing different things and aren’t interchangeable, and function calls relying on purity can reasonably be inferred to want to use the pure method.
With regards to frequency, I’m saying that disallowing this – complete overwriting of pure methods, rather than just adding a new impure method to a function – would presumably not be a big burden on anyone, since it’s very rare that people want to completely overwrite a method. (Especially one that you’d think of as pure.)
Thanks for giving the example of normal overloading, though – I see now why the proposal of just defaulting to the most specific pure method wouldn’t work, since even introducing a new pure method can create impure behavior. Yeah, that’s a real problem, and I’ll have to think about it.