Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework: protocol division requirements #115

Open
oscbyspro opened this issue Oct 13, 2024 · 2 comments
Open

Rework: protocol division requirements #115

oscbyspro opened this issue Oct 13, 2024 · 2 comments
Labels
addition oh, so shiny! brrr such code, much wow maybe to do, or not to do? subtraction huh? where did it go?

Comments

@oscbyspro
Copy link
Owner

oscbyspro commented Oct 13, 2024

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
}
@oscbyspro oscbyspro added addition oh, so shiny! brrr such code, much wow subtraction huh? where did it go? labels Oct 13, 2024
@oscbyspro
Copy link
Owner Author

It doesn't seem viable to derive the signed division from an unsigned requirement. Sad, but understandable.

@oscbyspro
Copy link
Owner Author

oscbyspro commented Oct 13, 2024

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.

@oscbyspro oscbyspro added the maybe to do, or not to do? label Oct 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition oh, so shiny! brrr such code, much wow maybe to do, or not to do? subtraction huh? where did it go?
Projects
None yet
Development

No branches or pull requests

1 participant