Feature request: `.values_mut_range(idx..)`

[Centril]

I was hacking on the compiler and I wrote:

                    // We've rejected overlap in each product in the sum.
                    // Now we must account for the possibility that or-pattern is a factor
                    // in a product. A basic case to reject here is `(V1(a) | V2(a), a)`.
                    let last_id = *prod_ids.last().unwrap();
                    bindings.values_mut().skip(len_before).for_each(|val| *val = last_id);

which is nice.

Maybe bindings.values_mut_range(len_before..).for_each(..) would be nicer?

[bluss]

Sounds good. We would need to bump to Rust 1.28 to use std::ops::RangeBounds trait.

1. Precedent in naming seems to be range_mut from BTreeMap
2. 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?
3. 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.

[Centril]

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. ;)

[cuviper]

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.

[bluss]

unpacking tuples from iteration is its own problem, would love a general solution for that.. 😉

[bluss]

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

[cuviper]

Ah, I missed the fact that SliceIndex is parameterize by the item type. Too bad.

[cuviper]

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().