See also: https://ridiculousfish.com/blog/posts/least-favorite-rust-type.html
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.
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?
For full irony, name it xrange.
That’s very funny. Wish I’d thought of it!