-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
TreeMap: find_equiv(_mut) for str-like keys #15220
Conversation
vhbit
commented
Jun 27, 2014
- it allows to lookup using any str-equiv object, making TreeMaps finally usable (for example, it is much easier to work with JSON with lookup values being static strs)
- actually provides pretty flexible solution which could be extended to other equivalent types (although it might be not that performant)
This seems to be taking issues like #12135 to the extreme by having a super-specialized implementation for just strings on keys that generally want I would personally be more in favor of finding a better For previous discussion, see #13205, #11074, #11691, #12135, and #14968. |
There is nothing could be done through One of solutions is to modify |
That is correct that |
It seems I'm missing something, the essence of BST-nature is So there could be a couple of cases:
or more general
although I haven't tested yet if the second one will work in Rust now. |
I was thinking something more along the lines of:
That way you tell the tree what you're doing and with a closure you can compare against anything you may want. |
I'm a bit confused here as actually it is exactly what this patch does (although my naming is not that good):
|
I was more talking about the public-facing API. The patch specializes string-like keys, and no others. I was thinking that the finding functions would be exposed for all keys so if I had a map of strings I could possibly do something like a case-insensitive lookup. |
Aha, got it, sorry for misunderstanding :-) Sounds good. Although I still vote for providing both ways:
|
I'd prefer to not single-out string-like keys specifically, which may mean axing |
Sorry for a delay, here is update. I'm still haven't axed One more related issue: #14549 |
The I would be more in favor of enhancing the json module with any helper functions while only having the closure-based function in the
|
It's exactly my point. I can't imagine why someone will need to re-implement those
While I mention So it is all about opportunity to compose a lot of "primitives" (strings, maps) together out of box without writing any additional boilerplate code. In my opinion, it is all about |
These containers should just expose methods taking a closure instead of using the trait. It doesn't make sense to have a trait like
Strings aren't meant to be special beyond the support for string literals. Special cases for certain primitives types is bad language design. A rope or small string type should be just as flexible, and anything preventing that is a bug. |
Yep, definitely this will work, but it actually addresses only the second part of "Simple things should be simple, complex things should be possible". Consider the following examples:
It could be much easier if there was a way to return a closure, in this case it could be done as:
which is not that simple, but still is quite nice. But I've failed to get anything like this to work using current closures. Any hints are appreciated.
It seems I wasn't clear. While I've mentioned |
@alexcrichton, documented, squashed, will appreciate comments on wording as writing docs in English sometimes blows my mind. And also waiting for the final decision regarding |
/// | ||
/// assert_eq!(ua.unwrap().as_slice(), "Curl-Rust/0.1"); | ||
/// ``` | ||
#[allow(dead_code)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This dead_code
allow shouldn't be necessary.
Axed |
Needs a rebase against #15540 |
But otherwise looks good to me! |
find_with/find_mut_with which use provided closure for navigating tree and searching as flexible as possible
Rebased |
- it allows to lookup using any str-equiv object, making TreeMaps finally usable (for example, it is much easier to work with JSON with lookup values being static strs) - actually provides pretty flexible solution which could be extended to other equivalent types (although it might be not that performant)
// | ||
// The only difference is that non-mutable version uses loop instead | ||
// of recursion (performance considerations) | ||
// It seems to be impossible to avoid recursion with mutability |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is no longer the case. The mutable version is almost identical now, except for a temporary variable to appease borrowck
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, fixed in #15749