Repository navigation
Rework: protocol division requirements #115
Description
So I'm working on (#68) and (#69). The most straightforward solution results in protocol requirements with Optional<Fallible<T>> return types (#95). It works, and it seems viable, but I wouldn't call it elegant. I have some other ideas, however. One option is deriving safe operations from unsafe protocol requirements returning T. Another option, that may or may not be viable, is deriving division operations from a safe-but-unsigned requirement. It depends on how well the derived same-size-but-signed operations can be optimized. Imagine something like this:
protocol UnsignedInteger {
static func quotient(_ dividend: Natural<Self>, by divisor: Nonzero<Self>) -> Self
}
Activity
oscbyspro commentedon Oct 13, 2024
It doesn't seem viable to derive the signed division from an unsigned requirement. Sad, but understandable.
oscbyspro commentedon Oct 13, 2024
Tangentially, one reason (although I'm not sure it applies here) to derive safe
Guarantee-like methods fromunsafeprotocol requirements is that allGuaranteetype conversions areconsuming, so you can't really use them to wrap things you've borrowed. Using an unsafe non-Guaranteeparameter is basically equivalent to hoisting theborrowingeffect, if that makes sense. I don't think it matters much in the case of integers (sincecopyis trivial or cheap), but it's something I've noticed while writing methods using theGuaranteeapproach.