feature iter_find_many #3350
feature iter_find_many #3350
Conversation
ehuss
added
the
T-libs-api
|
Just FYI, I think most standard library additions go through the API Change Proposal process. I'm reluctant to speak for the libs-api team, but I think that is the process they typically use for a change like this. |
|
I feel like this API is too overloaded. It's essentially just filter / filter_map + collecting into an array, with the former being stable APIs and the latter having lots of unresolved questions which would all apply to this API as well. |
|
This is not quite the same as filter or filter map I think. The use case is quite different. To achieve the same thing with filter map would take 6 or 7 lines of code likely. I like the API for find many, but I agree it definitely gets a little more dense for find_many_map. I think the trade off is worth it, but that’s a matter of taste.
|
Entirely poissible. This is my first contribution here so I may have got the process wrong. It seemed like this was the right place based off of The contribution book. |
|
Link to cuviper's comment on IRLO, and ewoolsey's comment that introduced those functions. I think they are well motivated but would work better as methods. |
Oh yeah perhaps I should have been more clear in this RFC. The intention 100% would be to implement them as methods. |
| ```rust | ||
| let mut v = vec![(0, 1), (1, 2), (2, 3), (3, 4), (4, 5)]; | ||
| let [left, right] = | ||
| v.find_map_many(&mut v, [&2, &3], |item, key| &item.0 == key, |item| &mut item.1).unwrap(); |
There was a problem hiding this comment.
Borrowing v and &mut v at the same time?
This comment was marked as resolved.
This comment was marked as resolved.
|
So where do things go from here? I would love to move forward with this if possible. So far it seems like the only complaint is that the api is a bit chunky. |
Rendered