10

Most times I see std::move posted on here, it's referencing the <utility> version.

The std::move in <algorithm> actually does what its name suggests, move, whereas the std::move in <utility> casts its argument to an xvalue, which is basically just a preprocessing step for eventually moving the xvalue into an lvalue. So isn't it kind of confusing for both of these to be named move when the functionality for each is different?

24n8
  • 1,898
  • 1
  • 12
  • 25
  • 1
    Possibly related question: [Why was std::swap moved from to ?](https://stackoverflow.com/questions/6086072/why-was-stdswap-moved-to-utility) – Brian61354270 Mar 18 '20 at 20:08
  • 3
    Yes, `move` should have been called `make_rvalue` or something along those lines. It's frustrating to explain time after time that the single parameter `std::move` doesn't actually move anything. – NathanOliver Mar 18 '20 at 20:09
  • The one in `` is simply the one in the `` applied to a whole range. – ph3rin Mar 18 '20 at 20:09
  • 1
    @KaenbyouRin Yes, but the one in `` actually does perform the move (assuming that there is a move assignment operator defined for the type we're moving). – 24n8 Mar 18 '20 at 20:11
  • @Brian Makes sense. I assume the committee decided the same thing with `std::move`? But it appears that the definition of `swap` didn't actually change when it moved from `` to ``. `std::move` in the 2 headers are quite different functions – 24n8 Mar 18 '20 at 20:12
  • @NathanOliver Technically, the multi-parameter `std::move` may also not move anything if there's not a move assignment operator defined for the type we're moving, right? – 24n8 Mar 18 '20 at 20:12
  • Yeah, if the type is not moveable then you'll get copies, but what I'm trying to get at is algorithm `move` actually does work, utility move just does a cast. – NathanOliver Mar 18 '20 at 20:15
  • @NathanOliver `std::move` matches the naming scheme of _move constructor_ and _move assignment_. I'd find `make_rvalue` more confusing actually (especially for newcomers). Arguably, `std::move` doesn't always result in a move so maybe `std::try_move` would be a better fit. – Timo Mar 18 '20 at 20:16
  • 1
    Hot take: they should have made `std::move` an operator instead of a library function. Any better name than `std::move` would have been longer, which sucks. – Brian Bi Mar 18 '20 at 20:16
  • There's another one in `` too! :-) – Howard Hinnant Mar 18 '20 at 21:32

1 Answers1

9

So isn't it kind of confusing for both of these to be named move?

It can be confusing, especially those who are not used to languages that support overloading. It is true that programming guidelines typically discourage overloads with separate meanings.

But it is also not very difficult to learn that there are two functions by the same name, although this is subjective. The different argument lists provide sufficient context to easily recognise one from the other.

Why is there a std::move in both and

Because the designers of the language chose to use the same name for both functions.

std::move is a very concise way to express both functions. The one in <algorithm> is complementary to std::copy from the same header.

whereas the std::move in casts its argument to an xvalue, which is basically just a preprocessing step for eventually moving

Describing what the function does is not the only thing that the name of the function can express. In this case, the name expresses the intention of the programmer who used the function: The programmer intends to move from the argument lvalue - if possible.

This is something that programmers may potentially need to write quite often; thus there is a need for very short name.

eerorika
  • 232,697
  • 12
  • 197
  • 326