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

Conform to borrowing convention from std #4

Open
jeffparsons opened this issue Feb 15, 2019 · 3 comments
Open

Conform to borrowing convention from std #4

jeffparsons opened this issue Feb 15, 2019 · 3 comments

Comments

@jeffparsons
Copy link
Owner

BTreeMap has signatures like...

    pub fn get<Q: ?Sized>(&self, key: &Q) -> Option<&V>
        where K: Borrow<Q>,
              Q: Ord

Using Borrow in RangeMap and RangeSet would be better than the plain borrows it has now.

@jeffparsons jeffparsons added the good first issue Good for newcomers label Feb 15, 2019
@jeffparsons
Copy link
Owner Author

I think this might not actually be possible, because core::ops::Range::contains doesn't use Borrow.

Compare:

And we would need to be able to pass a Q into core::ops::Range::contains.

I'm closing this for now. If someone else points out that it's actually possible somehow then I'll re-open it. But it should be backward compatible, so I'm no longer treating it as a 1.0-blocker just for completeness reasons.

@jeffparsons jeffparsons removed the good first issue Good for newcomers label Aug 24, 2021
@jeffparsons
Copy link
Owner Author

On second thoughts, this limitation only exists because of my current internal representation (and even with it I think I could work around it), so I'm going to re-open this. I'm thinking of trying a different internal representation anyway, so we'll see if that goes anywhere.

@jeffparsons jeffparsons reopened this Aug 24, 2021
@jeffparsons
Copy link
Owner Author

My attempts at implementing Borrow in ways that would let me work around this keep ending up conflicting with this blanket impl:

impl<T: ?Sized> Borrow<T> for T { ... }

I could hack around it on nightly using negative impls or specialization, but I haven't found any way to get around it on stable. I think I'll just let this sit for now and come back to it when one of those is stabilized, unless someone else comes up with a clever workaround in the meantime. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant