"Move" in the sense of https://stackoverflow.com/questions/3106110/what-is-move-sem...

Now, if you don't know what "move semantics" is, then "lvalues can't be moved from" isn't terribly helpful, and if you do then it's tautological, so I'm not saying you're wrong to criticize. :) But in a C++ context, "move" does have a single specific meaning — the one he's using properly if opaquely-to-non-C++ers.

"move" means to pass into an r-value reference function parameter, for instance a move constructor, move assignment operator, or forwarding reference.

He has a good article on that at [1]

But here's the gist: sometimes you have an object you want to copy, but then abandon the original. Maybe it's to return an object from a function. Maybe it's to insert the object into a larger structure. In these cases, copying can be expensive and it would be nice if you could just "raid" the original object to steal bits of it and construct the "copy" out of the raided bits. C++11 enabled this with rvalue references, std::move, and rvalue reference constructors.

This added a lot of "what the hell is this" to C++ code and a lot of new mental-model stuff to track for programmers. I understand why it was all added, but I have deep misgivings about the added complexity.

[1] https://blog.knatten.org/2018/03/09/lvalues-rvalues-glvalues...

> It used to always create a temporary right?

Temporaries could still be elided in some cases before, but the semantics were still understood in terms of temporary objects.

Now some forms of elision are mandatory and elision+RVO semantics are understood as objects being directly created into the final named location.

Getting failures later after coercing something to a reference is even easier than that; just deference a null pointer when passing to an argument that takes a reference; no warnings or errors! https://godbolt.org/z/xf5d9jKeh

To be fair, though, Rust really needs something morally like prvalues, to solve the heap initialization problem aka `Box::new([42; 10_000_000])`

    const HUGE: usize = 10_000_000;
    let mut values = Box::<[i32]>::new_uninit_slice(HUGE);
    for k in 0..HUGE {
         values[k].write(42);
    }

    let values = values.assume_init();

Additionally, the "r" and "l" may lead one to incorrectly guess that rvalues and lvalues are related to their position in an expression. But alas, they aren't; there are lvalues that cannot appear in the left-hand side of an expression.

The article specifically points out that this isn't about optimization. A temporary will not be created even with -O0 (you can observe this by putting logging into the copy and move constructors).

Yup - I wish that was not the case, I've learned relatively recently that the state the variable becomes (after moving) is "valid, but unspecified" - e.g. you can still destroy it (I guess how would RAII work otherwise), you can still assign to it, and even check some basic properties (!) - but you can't know anything about the actual value (contents) it carries (weird)

It's like a tombstone for a deleted file, object - something that tells you - "Here lived Obj B Peterson, was nice folk, but moved away to a higher place"

It may seem inelegant but it pretty cleanly addresses real edge cases in systems-y code where the object necessarily has a shorter lifetime than its associated memory for strict safety.

In these cases, something resembling "use after free" is unavoidable if the move is destructive even though the object is semantically dead. Putting the object in a sentinel state where it is alive but not usable captures the semantics of deferred destruction pretty well.

I agree the names are confusing. But it's just a simple matter of having a diagram nearby to remember which is which. (I think I first saw that diagram on Stack Overflow.)

There have been a lot of times in science when I have trouble remembering names but have no trouble at all understanding the concepts behind these names. I just keep an index card nearby. I noticed this tendency of mine as early as high school. For example, in chemistry I sometimes couldn't remember which is dextro and which is levo, but I understand chirality and know how they are different. In physics I sometimes forget which is the magnetic B field and which is the magnetic H field, though I understand the difference between them. I don't use these concepts often so I haven't internalized the names. I think it's totally alright to have a name–concept dissociation for these.

I think they wanted to preserve the meaning of the existing two value types. The naming is still bad, though, because it's inconsistent. For example, why should 'xvalue' belong to 'generalized lvalue' when it also belongs to 'rvalue'? Aren't 'l' and 'r' supposed to be opposites on the same dimension (movability)?

Here's a suggestion in retrospect:

         | ivalue  | pvalue
         ---------------------
  lvalue | ilvalue | (plvalue)
  rvalue | irvalue | prvalue

The current naming is confusing exactly because 'lvalue' should be a supertype in one dimension, just like 'rvalue', and not a subtype (here: 'ilvalue'). I think they took this shortcut because 'plvalue' doesn't really exist, but it's still inconsistent. Let's not even talk about 'xvalue' (here: 'irvalue').

Not exactly. This was originally submitted 6 days ago, and was put in the SCP but took till now to get on the front page. Just as the discussion was developing, the original submission "expired" and disappeared from the front page.

Given that it's an active discussion with all comments posted in the past few hours, I've created a new copy to give it its full opportunity for visibility and discussion.