Ban infinite dividends

[oscbyspro]

Banning infinite dividends seems like the simplest solution to (#68). It would also mean that all safe division inputs are well-behaved. Infinite dividends would be banned by setting the type to Finite<T>. Imagine the following with some conveniences:

protocol BinaryInteger {
    static func division(_ dividend: Finite<Self>, by divisor: Nonzero<Self>) -> Fallible<Division<Self, Self>>
}

[oscbyspro]

Infinite-by-infinite division is well-behaved but also uninteresting; it's a conditional subtraction. I could add nicher constraints than Finite<T> and Natural<T> but I prefer to keep it simple ™️ to the extent that it is possible.

[oscbyspro]

I've prototyped a new approach using (#95). It seems a bit annoying to maintain, but otherwise viable. I could, perhaps, reduce it to just Optional<T> since the there's only one finite error case, T.isSigned && a == T.min && b == -1. I'm not yet convinced that taking such shortcuts is a good idea, however.

[oscbyspro]

I've had other ideas too. Like, I could strengthen the input guarantee such that only well-behaved divisions are allowed, basically hoisting all preconditions. That might be convoluted in another way, but I don't want to dismiss the idea just yet.

[oscbyspro]

I basically want the Fallible<T> part because of invariants like this:

I8(-128).quotient(Nonzero(-1)) == I8.exactly(IXL(-128) / IXL(-1))

Division is just a weird operation where almost all inputs are valid. Sigh.

[oscbyspro]

Back to the original post: divisions of infinite dividends are useless; a blanket ban is a viable alternative.

[oscbyspro]

I'll resolve this issue by tomorrow. The combinatorial maintenance hazard of implicit error propagation was the biggest blocker and it was resolves by moving on to the new sink approach (#116) (#117).