-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Change Copy to Clone in trait requirements as appropriate #65331
Conversation
r? @TimNN (rust_highfive has picked a reviewer for you, use r? to override) |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
7967870
to
6e82c19
Compare
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
(Have you double checked that there's no |
This is about |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
RFC 839 states |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
This appears to have introduced a minor backwards compatibility problem due to the new ambiguity between &T and T extend calls. New trait implementations is oftentimes considered acceptable breakage, however I don't feel like I have enough background knowledge to say whether this is or not. |
cc @rust-lang/libs |
With #65331 (comment) on how the status quo was a design choice and #65331 (comment) on how this change introduces introduces compat issues, I think we’ll want more motivation than “it seems preferable”. What are some concrete use cases that this enables? Can they all also be achieved today with an extra |
These are all excellent questions, whose answers do not motivate merging this right now. I just spotted an arbitrary improvement I could make, and made it. I have no use case, and no motivation for this other than "why not?" With that said, I'm closing this. |
Thank you for looking into this, even if it it didn’t work out! |
I spotted a few places in std requiring
Copy
where we didn't appear to be getting any benefit from requiring it overClone
.Clone
is implemented for more types, so it seems preferable to use it where we can.This won't break any backwards compatibility as
Clone
is a requirement ofCopy
.