1. 21
  1.  

    1. 1

      Given that, like the author of this article says, the goals of the Range type are in tension (and I agree, I found it a pretty frustrating abstraction to get to terms with), I wonder if, rather than constraining the goals of a greenfield range type, they could all be more smoothly achieved with a typestate-based API. I’m conjecturing this based on pure intuition because I think it would take some real experimentation to determine whether that’s actually viable, but it feels like a possibility. Also intuitively, though, I wonder if using typestates might make for an unacceptably costly abstraction in the context of something designed for general use.

    2. 1

      I wonder what a crate that implements such a feature set would look like and how it would feel to use. To use it, you’d have to write the full version of new_range(x, y), but otherwise it should be a drop in replacement in your own code, right?

      1. 7

        For full irony, name it xrange.

        1. 1

          That’s very funny. Wish I’d thought of it!