[fasquoika]

>A safe alternative is to use indexes instead of references.

    struct ParsedFile {
        contents: Vec<u8>,
        words: Vec<(usize, usize)>
    }

>This works well, and you can make it ergonomic by wrapping the index pair in a new type

You should probably just use the std::ops::Range type for this. It's what's created by the `..` syntax

[bobbylarrybobby]

Eh, Range has a lot of really weird stuff going on that is worth shying away from if possible. For instance they're Iterator and not Copy so if you try to iterate over them multiple times or pass them as indices multiple times, you're gonna have a bad time (i.e., you'll need to clone every time you do). Usize is Copy, so you can use them to construct a Range every time you need one and never run into those issues.

[steveklabnik]

Yes. For anyone who's not up on extremely obscure standard library issues in Rust, the Range type kind of serves two different purposes. One is the general concept of a range, and the other is an iterator over a range. Range is more of the latter, and copying iterators does slightly weird things (the behavior is contrary to some human intuition, even though the behavior is consistent), and so it was decided that Range shouldn't be Copy. But for the generic "I want a range of numbers" case, you would want that to be Copy. So there's a push and pull here. It seems like some of the latest discussion (and this has been going on for years) is that maybe this decision was wrong and even though the iterator behavior is weird ranges should start being Copy, but no decision is made yet. But when you're not doing iteration directly, imho you probably should just use a tuple of (start, end) rather than a Range, even though that may feel a bit odd.

Also: it's weird and really unfair imho that the GP is downvoted. While it is true that some folks have a different opinion, it's extremely subjective, and downvoting them for a slightly minority opinion doesn't seem right to me. I upvoted it, personally.