Comments (7)
We would need to bump to Rust 1.28 to use
std::ops::RangeBounds
trait.
That or SliceIndex
, as used by Index<I> for [T]
, but that's still 1.28. We could cfg-gate this for rustc version though.
The methods similar to the regular hash map get preference, and the index methods get names with "index" in them or similar. But in this case, we don't have key ranges at all, so we can go directly with an unadorned name for something that uses index ranges?
Or maybe use slice
-based names to make indexing clearer?
The old WIP #47 is also possibly relevant here.
@cuviper suggested on Discord that the iterator structs could possibly be reused.
Right, the idea being that the existing iterators are all just built on slice::Iter
and slice::IterMut
, so we could just start with a sub-slice when constructing them.
from indexmap.
Sounds good. We would need to bump to Rust 1.28 to use std::ops::RangeBounds
trait.
- Precedent in naming seems to be
range_mut
fromBTreeMap
- The methods similar to the regular hash map get preference, and the index methods get names with "index" in them or similar. But in this case, we don't have key ranges at all, so we can go directly with an unadorned name for something that uses index ranges?
- I'd prefer
range
,range_mut
,key_range{,_mut}
,value_range{,_mut}
for consistent names?
If we're frugal we only supply the two first just to avoid having a lot of iterators - then you have a key-value iterator, but it looks like that works almost just as well in the given code.
from indexmap.
If we're frugal we only supply the two first just to avoid having a lot of iterators - then you have a key-value iterator, but it looks like that works almost just as well in the given code.
@cuviper suggested on Discord that the iterator structs could possibly be reused. I'd personally prefer not to unpack that tuple or use tuple indexing. ;)
from indexmap.
unpacking tuples from iteration is its own problem, would love a general solution for that.. 😉
from indexmap.
I might be confused about how exactly to use SliceIndex, but this interface is not suitable for this kind of api - SliceIndex<X>
contains the type of whatever you are indexing in the X
, which means we would need to leak a private type in the trait bound. It makes it clear SliceIndex is not very useful outside its main application, implementing slicing on slices and str.
Just to record this information, and we go on to look at some trait that is made to be an extensible general interface - RangeBounds should be good.
I'll put this here so that you can share my 😞
pub fn values_slice_mut<I>(&mut self, range: I) -> ValuesMut<K, V>
where I: std::slice::SliceIndex<[Bucket<K, V>], Output=[Bucket<K, V>]>
error[E0446]: private type `Bucket<K, V>` in public interface
from indexmap.
Ah, I missed the fact that SliceIndex
is parameterize by the item type. Too bad.
from indexmap.
Maybe
bindings.values_mut_range(len_before..).for_each(..)
would be nicer?
Now that we have map::Slice
, you can write this like bindings[len_before..].values_mut()
.
from indexmap.
Related Issues (20)
- error[E0152]: duplicate lang item in crate `std` (which `indexmap` depends on): `panic_impl`. HOT 4
- ICE from indexmap or its dependency hashbrown HOT 4
- Using new seems impossible with FxBuildHasher HOT 2
- Exposing with_capacity with custom hasher? HOT 3
- Benchmark results HOT 1
- Feature request: Similar method to `Vec.splice` HOT 4
- Ordered Serialization HOT 3
- `binary_search` and `partition_point` on `Slice` HOT 4
- Feature request: Add Index<usize> to Keys HOT 1
- Implement (behind a feature branch) the Merge Crate HOT 4
- IndexMap doesn't implement `Hash` HOT 1
- Compilation bug HOT 1
- Organization / repo home HOT 12
- Doc link on crates.io is dead. HOT 3
- Kaspersky detected the indexmap build-script exe as malware (false positive) HOT 1
- MutableKeys for IndexSet HOT 2
- implement get_many_mut HOT 1
- serde_json::to_string serializes (key, value) HOT 3
- Request: add example to README
- Thanks :)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from indexmap.