-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 core::mem::copy
to complement core::mem::drop
.
#95534
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
An alternative to this is to add |
Spitballing: in the vein of I have no idea where it would live, though. It'd probably want to be sealed if it were a method, since anyone overloading it would always be wrong to do so. |
|
As a sketch, I could imagine something like this:
But maybe that's overkill, I don't know.
I don't follow this comment. You can still get a function pointer to a trait method the same as to a generic function. |
But that fails if the trait is private: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f1d46b2fba47b3b492d1a5d2eafa8446
|
and you can't
|
You'll note that I didn't seal the trait. (The overlap rules would need it from being implemented without specialization anyway.) Then imported it That does seem to work: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0aea6bf318c412ab0fd029d2bb28179f |
Ah interesting, yes you're right that it does the same thing as |
Yeah, I'm also not convinced by it. We'll see what libs-api thinks of stuff. I think what I'd really want is this: pub trait Clone {
fn clone(&self) -> Self; // as today
#[sealed]
fn copy(&self) -> Self { *self }
} so it's a small change, the method can be feature gated still, nobody can ever override it, thus unsafe code can still rely on it being actually a copy, and passing But that attribute doesn't exist today. Maybe I should (find someone else to) write an MCP/RFC for it. Arguably the |
I think that even if there were a postfix version of copy, having a standalone That said, I would very much love to see a way to do a postfix copy, although I'm less sold on the idea of it being a method as I am on a dedicated postfix deref operator, like zig has. This is a bit beside the point, though; while I think this version of copy is easy to add here in a PR, such an operator would require an RFC to be properly fleshed out. |
Seems fine to experiment with; we can evaluate it more before stabilization. @bors r+ |
📌 Commit bbc39287a417b17feaf054c2b76f8aa982b7e38c has been approved by |
Shouldn't this have a tracking issue before merging? cc @joshtriplett |
@bors r- |
Yes, it should. |
This is useful for combinators. I didn't add `clone` since you can already use `Clone::clone` in its place; copy has no such corresponding function.
Good catch, thanks, fixed. @bors r=joshtriplett rollup |
📌 Commit 9ac6277 has been approved by |
Add `core::mem::copy` to complement `core::mem::drop`. This is useful for combinators. I didn't add `clone` since you can already use `Clone::clone` in its place; copy has no such corresponding function.
Rollup of 4 pull requests Successful merges: - rust-lang#95534 (Add `core::mem::copy` to complement `core::mem::drop`.) - rust-lang#97912 (Stabilize `Path::try_exists()` and improve doc) - rust-lang#98225 (Make debug_triple depend on target json file content rather than file path) - rust-lang#98257 (Fix typos in `IntoFuture` docs) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This is useful for combinators. I didn't add
clone
since you can alreadyuse
Clone::clone
in its place; copy has no such corresponding function.