If this is about the issue with factorize, I think a dynamic error is probably preferable, because most people’s code won’t do thay dynamically but changing the type might break code that never used it in a weird way

Got it, it was

Even a dynamic error is an incompatibility, though—you think this one is worth breaking?

Is just changing it to the right answer a possibility?

That is of course also incompatible in some sense, but it seems much less bad.

Well, the thing is that there’s not a clear “right answer” here.

The “best answer” I could imagine is having (factorize 0) return '((0 1)) in other words to have 0 factorize as 0^1

But this would break a different plausible invariant, which is that the first element of each pair is a prime.

In other words, the issue is that there isn’t an unambiguous right answer. Raising an error (or even better having a type check) is a good escape in this situation

But it is of course not backwards compatible

Runtime error seems best to me, but if we prioritize strict b.c. we could produce a warning this release and error next release, or similar

This sounds as a good solution (the runtime error that is).

The documentation reads:

I think the choice was made to make easier to use in context with the other number theoretic functions - but I am not 100% sure.

Runtime error sounds right to me too