The call to a move cons/move assign does not happen at call time. When a function taking rvalue reference is called, it can still have two code paths, one that copies the argument, and one that moves it.

All the && does is prevent lvalues from being passed as arguments. It's still just a reference, not a move. Indeed, in the callee it's an lvalue reference.

But yeah, you can statically check if there exists a code path that calls the copy cons/copy assign. But you'll need to check if the callee calls ANY type's copy cons/assign, because it may not be the same type as the passed in obj.

At that point, what even is a move? char*p = smartptr.release() in the callee is a valid move into a raw pointer, satisfying the interface in callee. That's a move.[1] how could you detect that?

[1] if this definition of move offends you, then instead remember that shared_ptr has a constructor that takes an rvalue unique_ptr. The move only happens inside the move constructor.

How do you detect all cases of e.g. return cons(ptr.release()) ? It may even be the same binary code as return cons(std::move(ptr))

Probably in the end shared pointer constructor probably calls .release() on the unique ptr. That's the move.

Yup. That's what https://en.cppreference.com/w/cpp/memory/shared_ptr/shared_p... says.

(Sorry, on phone so not full code. Hopefully I stopped autocorrect all times it interfered)

What the callee does it out of scope. We are talking about a single assignment or construction of a variable. This has nothing to do with tracing execution. It happens at one place, and you can look at the place to see if it is using a copy or move contructor.

When talking C++ move semantics it's easy to talk past each other. So I'm not sure what your claim is. Another commenter said that one can tell if something is moved or not without looking at the body of the callee. Is that what you're saying? Because you can't.

I apologize if you're making a different claim, but I'm not clear on what that is.

Anyway, for my point, here's an example where neither copy nor move happens, which one can only know by looking at the body of the callee: https://godbolt.org/z/d7f6MWcb5

By changing only the callee we can cause a move: https://godbolt.org/z/b8M495Exq

Equally we can remove the use of `std::move` in the callee, and now it's instead a copy. (of course, in this example with `unique_ptr`, it means a build failure as `unique_ptr` is not copyable)

> [assignment or construction of a variable] happens at one place

Not sure what you mean by that. The callee taking an rvalue reference could first copy, then move, if it wants to. Or do neither (per my example above). Unlike in Rust, the copy/move doesn't get decided at the call point.

You can, at one point, statically determine if the (usually const) single ampersand reference function is called, or the rvalue reference function, via standard polymorphism. But that's not the point where the move cons/assign happens, so for that one has to look in the callee.

Calling a function that takes a rref will never use a move constructor to create the parameter. We can statically know that both of your foo functions will not use a move constructor when constructing p.

>By changing only the callee we can cause a move

This move is for constructing t. p still is not constructed with a move constructor.

p in the callee is not constructed at all. It's a reference.

> Calling a function that takes a rref will never use a move constructor to create the paramete

This is what I mean by talking past each other. This is literally what I said.

Well, I wouldn't say the parameter is "created", since I'd say that's an imprecise term in this context.