Well since you're saying "physically" I guess we should talk about a concrete thing, so lets say we're compiling this for the archaic Intel Core i7 I'm writing this on.

On that machine Data is "physically" just the Vec, which is three 64-bit values, a pointer to i32 ("physically" on this machine a virtual address), an integer length and an integer capacity, and the machine has a whole bunch of GPRs so sure, one way the compiler might implement FactoryFuncton is to "physically" copy those three values into CPU registers. Maybe say RAX, RCX, RDX ?

Actually though there's an excellent chance that this gets inlined in your program, and so FactoryFunction never really exists as a distinct function, the compiler just stamps out the appropriate stuff in line every time we "call" this function, so then there was never a "parameter" because there was never a "function".

▲ weinzierl 5 days ago | parent [-]

True. When I wrote the comment I did not think about the Vec though.

The point I am trying to make is more general:

I believe that when you have a type in Rust that is not Copy it will never be implicitly copied in a way that you end up with two visible instances but it is not guaranteed that Rust never implicitly memcopies all its bytes.

I have not tried it but what I had in mind instead of the Vec was a big struct that is not Copy. Something like:

   struct Big<const M: usize> {
       buf: [u8; M],
   }

   // Make it non-Copy.
   impl<const M: usize> Drop for Big<M> {
        fn drop(&mut self) {} 
   }

From my understanding, to know if memory is shoveled around it is not enough to know the function signature and whether the type is Copy or not. The specifics of the type matter.

▲

catlifeonmars 5 days ago | parent | next [-]

Wouldn’t you need a Pin<T> to guarantee no copying? I think copy has two different meanings, depending on whether you’re talking about the underlying memory representation and the logical representation that is available to the developer.

Obviously the distinction can matter sometimes and thus copy in the logical sense is a leaky abstraction (although in practice I notice I do not see that leakage often).

▲

tialaramex 5 days ago | parent | prev [-]

Yes, Rust absolutely might memcpy your Big when you move it somewhere.

I will say that programmers very often have bad instincts for when that's a bad idea. If you have a mix of abilities and can ask, try it, who in your team thinks that'll perform worse for moving M = 64 or M = 32? Don't give them hours to think about it. I would not even be surprised to find real world experienced programmers whose instinct tells them even M = 4 is a bad idea despite the fact that if we analyse it we're copying a 4 byte value rather than copying the (potentially much bigger) pointer and taking an indirection

Edited: To fix order of last comparison

	▲	ninkendo 5 days ago \| parent [-]
		> I will say that programmers very often have bad instincts for when that's a bad idea True that. memcpy is basically the literal fastest thing your processor can do, it’s trivially pipelined and can be done asynchronously. If the alternative is heap storage you’re almost always cooked: that heap space is far less likely to be in L1 cache, allocating it takes time and requires walking a free list, dealing with memory fragmentation, freeing it when dropped, etc. It’s not a bad short-hand to think of the heap as being 10-100x slower than the stack.