-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add missing Copy/Clone impls for Iterators #47304
Conversation
r? @dtolnay (rust_highfive has picked a reviewer for you, use r? to override) |
The |
@eddyb Sure-- I'll split it out. Sorry, I think there's some history here that I'm not aware of. |
fb8364b
to
d7de4d2
Compare
I'm inclined to say that it's unlikely we'll accept Copy iterators at this point -- from past discussion(s) the current consensus seems to be that it's too error prone to have them since accidentally copying is too easy. That may have since changed, though. |
@Mark-Simulacrum I thought there was a consensus that if we add lints we can get away with it. |
Could we impl Copy for Range if that's the case? 🤩 |
Not sure. Seems okay, and probably doesn't affect too many crates in practice. I'm okay with this, but do think we should get consensus before going ahead with it from at least some of the libs team. |
@kennytm Well, yes, but again, it's predicated on someone actually writing those lints. |
I think we should add some sort of lint. It's not that hard. Then let's aggressively add I had previously opened #45683 for tracking that. I can put up some kind of simple, first-step proposal. |
…ddyb Use copy/clone closures to simplify calendar test Split out from rust-lang#47304 r? @eddyb
…ddyb Use copy/clone closures to simplify calendar test Split out from rust-lang#47304 r? @eddyb
…ddyb Use copy/clone closures to simplify calendar test Split out from rust-lang#47304 r? @eddyb
Closing to keep the PR set clean until we've got the appropriate lint in place. |
There's a bit of an open question here that probably requires some libs/lang team discussion: do we want to implement
Copy
forIterator
types, or are the ergonomic and performance benefits outweighed by the potential for confusion? @nikomatsakis previously proposed introducing aCopy
-lint that would warn against types that usually wouldn't beCopy
d. Personally, I think we should implementCopy
for nearly any type possible to allow users the flexibility to make their own iterator-containing typesCopy
where appropriate.