3 ms·

I actually love this type. Specifically because you can build ranges over complex key types. For example, two keys in a BTreeMap can be used to define a range s

• ShroudedNight 6y ago
  The example you provide appears to be using the same type for both beginning and ending values, and would also appear to explicitly provide an ordering (<=). Maybe I missed something, but that level of abstraction did not seem to be what was under indictment in the article, but rather scenarios where the types of first and last were disjoint, or the values were incomparable.
  • tomjakubowski 6y ago
    Range<Idx> only has one type parameter. Thankfully, you really cannot have a range with an i32 on one end and a String on another. It's also not possible to call methods like contains() on Range<Idx> unless the type is (Partial?)Ord, because of the constraint on Idx in the impl which defines those methods.
• djur 6y ago
  Seems to me that you could still have this syntactic sugar if you use a separate type for iterable ranges and non-iterable bounds and then have them both implement RangeBounds.
  • bluejekyll 6y ago
    I think you’d still want something where all the types Barrow to something consistent type. Otherwise, PartialEq/PartialOrd becomes complex to reason about. I haven’t tried this, but maybe the Idx of Range could be Borrow, much like the get requirements on HashMap.