-
Notifications
You must be signed in to change notification settings - Fork 304
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
More generic maps in GroupingMap
(v2)
#906
base: master
Are you sure you want to change the base?
More generic maps in GroupingMap
(v2)
#906
Conversation
Note: `BTreeMap::remove<Q>` and `BTreeMap::remove<Q>` both accept a more general `Q` rather than just `Self::Key`. If ever needed, `Map<Q>` would be possible (with the same bound on `Q` than `Self::Key`: `Ord` or `Eq + Hash`). Implement `Map` for simple unordered `Vec<(_, _)>`. Note it uses `swap_remove`.
This is a huge but quite straightforward transformation: - `GroupingMap[By]` becomes `GroupingGenericMap[By]` with a generic type `M` - `K: Hash` becomes `M: Map<Key = K>` - `HashMap<K, ...>` becomes `M` with a `M: Map<Value = ...>` bound - Remove `Hash` and `HashMap` - `use_std` becomes `use_alloc`
This is a breaking change! However, this is mostly inferred. Note that it breaks (only) laziness tests because the `GroupingMap` object is not used (I could write any type but `u8` is one of the possible returned types). If it was used then it would have been inferred. I copied/pasted the code of old `into_grouping_map[_by]` methods, added the generic `R` and updated each function body with `_in(.., HashMap::new())`. The old types are aliases of the new ones.
GroupingMap
GroupingMap
(v2)
rust-itertools#901 (comment) SkiFire13 had the idea this could be optimized for vectors.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #906 +/- ##
==========================================
- Coverage 94.38% 94.00% -0.39%
==========================================
Files 48 49 +1
Lines 6665 6905 +240
==========================================
+ Hits 6291 6491 +200
- Misses 374 414 +40 ☔ View full report in Codecov by Sentry. |
To generalize the "quick tests", I would need to generalize @SkiFire13 I was able to make it work with a single additional generic parameter. @phimuemue @jswrenn Do you think such breaking change is acceptable? I worry it might be too nasty for very few people. |
This an alternative to #901 that I learnt from, it would close #901, close #588 and eventually solve most generic-containerGeneric vector/hasher/map
issues.
Map
polished earlier.GroupingMap[By]
intoGroupingGenericMap[By]
This is a huge but quite straightforward transformation:
GroupingMap[By]
becomesGroupingGenericMap[By]
with a generic typeM
K: Hash
becomesM: Map<Key = K>
HashMap<K, ...>
becomesM
with aM: Map<Value = ...>
boundHash
andHashMap
use_std
becomesuse_alloc
GroupingMap[By]
with one more generic parameterThis is a breaking change! However, this is mostly inferred.
Note that it breaks (only) laziness tests because the
GroupingMap
object is not used (I could write any type butu8
is one of the possible returned types). If it was used then it would have been inferred.I copied/pasted the code of old
into_grouping_map[_by]
methods, added the genericR
and updated each function body with_in(.., HashMap::new())
.The old types are aliases of the new ones.
The main interest of this PR over #901 is that there is not
_in
versions for eachGroupingMap
method.More than the additional parameter, the following code (weird but currently working) would not compile anymore.
However, it's easily solvable here,
.into_grouping_map_by(|n| n % 2)
should be moved to both branches for the code to work as before.Now, in other cases, it might be not that easily solvable! Is it a too big breaking change?