Tracking Issue for core::mem::copy

[jyn514]

Feature gate: #![feature(mem_copy_fn)]

This is a tracking issue for core::mem::copy, which is a way - like mem::drop - to copy a value without creating a new closure.

Public API

// core::mem
pub fn copy<T: Copy>(x: &T) -> T {}

Steps / History

• Implementation: Add core::mem::copy to complement core::mem::drop. #95534
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Should we find a way to make this an associated function on Copy instead?

[eggyal]

If you have x: &T where T: Copy, why would you want core::mem::copy(x) when you can instead do *x? Won't that just be the implementation of this function?

[jyn514]

@eggyal it's the difference between option.map(|x| *x) and option.map(copy). The second is easier to read and write.

(In this particular case, there's Option::copied, but there's not Result::copied_err or anything; and this is useful for custom types too)

[DutchGhost]

Why not make it const right away?

pub const fn copy<T: Copy>(x: &T) -> T {
    *x
}

compiles on stable...

[eggyal]

Why not make it const right away?

Of course, this works if it's a free function; but would not (for now) if it's made an associated function on the Copy trait—so perhaps that alone might resolve the unresolved question ?

[Lokathor]

i'm mildly concerned that std::mem::copy and std::ptr::copy both would exist but do very different sorts of things. Can we call this new function copied, same as the iterator/option method?

[jyn514]

Hmm sure, copied seems fine.

I do think that all the functions in std::ptr are kind of expected to deal with raw memory; I don't think it would be hard to tell them apart in practice. But I don't feel strongly.

[Lokathor]

in an ideal world everything could be fully imported, so this helps the ideal.

[jyn514]

prior art:

rust/compiler/rustc_middle/src/ty/query.rs

Lines 109 to 113 in 7b8e2a5

	/// Helper to ensure that queries only return `Copy` types.
	#[inline(always)]
	fn copy<T: Copy>(x: &T) -> T {
	*x
	}

[aleksanderkrauze]

I think this function should be marked #[must_use] as well.

[Stargateur]

I feel this method while useful may be premature, specially we already have other solution like copied() and cloned(), I advice we wait for a strong demand before make this a stable method. I don't think I ever needed such thing except for few case in Option or Iterator that already have solution for that. If this copy is not in the prelude (hiding in mem module), there is very few reason to have it, write the closure could be as fast. Copy::copy would be better.

[KSBilodeau]

To throw my hat in the ring here, I actually ran into a helpful use case for this function today. Using the unstable iter_next_chunk api on an vector of u8s, I got a Result<[&u8; 4], ...>, which cannot be converted easily to [u8; 4] with copied and either requires the length .map(|x| *x) or this lovely lil std::mem::copy function.