Open oscbyspro opened 3 days ago
It doesn't seem viable to derive the signed division from an unsigned requirement. Sad, but understandable.
Tangentially, one reason (although I'm not sure it applies here) to derive safe Guarantee
-like methods from unsafe
protocol requirements is that all Guarantee
type conversions are consuming
, so you can't really use them to wrap things you've borrowed. Using an unsafe non-Guarantee
parameter is basically equivalent to hoisting the borrowing
effect, if that makes sense. I don't think it matters much in the case of integers (since copy
is trivial or cheap), but it's something I've noticed while writing methods using the Guarantee
approach.
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 returningT
. 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: