-
Notifications
You must be signed in to change notification settings - Fork 3
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
Remove type parameter from Natural
(WIP)
#14
Comments
CC me (need to think about this a bit more...) |
I've only looked at this crate for a very short while. How to handle the Without a type parameter on I tried the following, which fails because the default comparator is pub fn contains<Q: ?Sized>(&self, key: &Q) -> bool
where K: Borrow<Q>,
C: Compare<Q>,
{ With this said, I think for this use case a phantom-type based approach works better. Custom closure comparators can't cope with the Q vs K scheme anyway. |
This is super out of cache but I think the Borrow adaptor is supposed to be for that...? https://github.com/contain-rs/compare/blob/master/src/lib.rs#L215-L234 |
aha thanks! |
Hm I can't figure out how to use it. I don't think I can, if I require my |
The only reason this type parameter is currently necessary is because of the design of the comparator adaptors. Without the parameter (and replacing the
natural
function with a unit struct), the extremely commonfails type inference:
This is because the
rev
method is defined on theCompare
trait itself, which has two type parameters (for the left- and right-hand sides of the comparison), and the specific impl to use here is unconstrained.However, the behavior of the
rev
method is always the same, regardless of the concrete comparator type or the type parameters involved. Therefore, there should really only be one way (impl) to reverse a comparator, which leads to a few possible solutions. They cannot involve type parameters onCompare
.1. Use separate constructors
Freestanding function:
Constructor method:
Public field:
This approach has the following downsides:
The user must import an additional type or function for each adaptor. (This is potentially negated by the custom prelude RFC).
Chaining is no longer possible, which can make things confusing. For example:
versus
2. Use a separate trait
With a blanket impl:
With specific impls:
TODO: Other options.
The text was updated successfully, but these errors were encountered: