Impl Copy for Range

[jyn514]

From rust-lang/rust#48649 (closed as needing an RFC): It would be nice for Range<Idx: Copy> to implement Copy.

I want to store a Range in a struct, but that prevents me from making the struct Copy. I can make a (start, end) struct that wraps it but that seems a little silly.

With Range from the standard library (playground):

use core::ops::Range;

// error[E0204]: the trait `Copy` may not be implemented for this type
#[derive(Copy)]
struct HasRange {
    r: Range<usize>,
    other_field: usize,
}

// works fine
struct HasRangeWrapper {
    r: RangeWrapper,
    other_field: usize,
}

#[derive(Copy, Clone)]
pub struct RangeWrapper {
    start: usize,
    end: usize,
}

// Note that Range is isomorphic to RangeWrapper;
// you can convert freely between the two
impl From<Range<usize>> for RangeWrapper {
    fn from(range: Range<usize>) -> Self {
        Self { start: range.start, end: range.end }
    }
}

impl From<RangeWrapper> for Range<usize> {
    fn from(range: RangeWrapper) -> Self {
        Self { start: range.start, end: range.end }
    }
}

There is more discussion of pros and cons in the rust-lang/rust issue.

[tesuji]

Clone it?

[Lokathor]

That's clearly less ergonomic than just letting the range be copy.

having range itself be an Iterator and not turn into an iterator is very obviously a design flub at this point, and hopefully an RFC can fix it in some later edition.

[RustyYato]

This is not possible to fix in an edition (I think), so this is non-actionable. Ranges are explicitly not Copy because that could induce weird behaviors in combo with Iterator (this is the same reason why slice::Iter is not Copy even though it could be).

[Lokathor]

Yandros proposed in the issue linked in the OP how, in an edition change, you could remove Iterator from being on Range directly and then give it Copy.

And honestly ive never been clear on what's allowed as an edition change or not. This proposal would be able to compile to the same MIR layer as not using this proposal, so my basic understanding is that it should be possible with an edition change, even if the libs team doesn't end up doing it.

[kennytm]

Adding a Copy impl doesn't require a new edition. However, it would be a total departure from the current practice that Copy and Iterator are mutually exclusive (this is not strongly tied to editions).

---

• doing semver-compatible changes (e.g. adding a Copy to Range) doesn't need a new edition
• incompatible changes to the language itself requires a new edition (assuming both new and old editions are supported by the same MIR)
• incompatible changes to the standard library is prohibited and requires "Rust 2" (e.g. remove Iterator from Range).

[jyn514]

Clone it?

I really don't want to do this since my struct is copied over 150 times throughout the code base. I'm using RangeWrapper in the meantime.

Ranges are explicitly not Copy because that could induce weird behaviors in combo with Iterator

the current practice that Copy and Iterator are mutually exclusive

Can you expand on this? Why doesn't Copy play well with Iterator?

[burdges]

Is there any actual soundness issues with an Iterator being Copy? In fact &T is Copy.

Is it just to avoid impl<I: Copy> Copy for A<I> for many iterator adapters A?

Or is it some performance concern because a tree of loops gets expensive fast? How would that come up?

[sfackler]

This is not a soundess question. Iterator and Copy are both safe APIs, so I don't understand how soudness or the copyability of references would be involved here..

We don't want iterators to be Copy because they are stateful objects, and a Copy stateful object can be copied accidentally, causing unexpected behavior.

[CryZe]

It more seems like there should've been proper IntoIter'd types for ranges then instead of having ranges directly be iterators. Though that would've possibly not been all too ergonomic either.

[burdges]

I see: It's not a performance concern either, so much as a correctness concern. It'd be too easy to make mistakes. It's the same reason &[T] does not satisfy Iterator.

Yes some simple wrapper type like pub struct RangeIter<I>(I); plus the extra impls works here.

[sfackler]

Yeah, in hindsight IntoIterator impls would have been a better approach. In addition to the Copy problem, there's some jank in RangeInclusive that we would have been able to avoid.

[burdges]

At least doing this does not break for loop syntax, so nothing too problematic really, but..

I'm afraid impl<I: Iterator> IntoIterator for I prevents adding pub struct RangeIter<I>(I); before removing impl Iterator for Range, etc., so maybe specialization should land before beginning the edition process?

[sfackler]

We cannot remove impl Iterator for Range. That is a breaking change.

[cmyr]

Just want to chime in to add a little bit of anecdata, which is that I have now on at least three occasions had to search out why Range<T> isn't Copy when T: Copy; it's unexpected and is definitely a papercut. I do a lot of work with text and it is very common to store a range in a struct or similar, and to want to do something like let line_text = &buffer[line.range]. Cloning works, but it feels wrong.

[BurntSushi]

@cmyr Yeah, same, which has led to things like this: https://docs.rs/grep-matcher/0.1.4/grep_matcher/struct.Match.html#indexing