Proper way to handle "alias this" deprecation for classes

[H. S. Teoh]

On Wed, May 10, 2023 at 03:24:48PM +0000, Chris Piker via Digitalmars-d-learn wrote:
[...]
> It's off topic, but I forget why managing memory for rvalues* was
> pushed onto the programmer and not handled by the compiler.  I'm sure
> there is a good reason but it does seem like a symmetry breaking
> requirement.
> 
> --
> *or was it lvalues, I can never keep the two separate.  Wish the some
> other terminology was adopted long ago, such as "named" vs.
> "ephemeral".

	x   =   y;
	^       ^
	|       |
	lvalue  rvalue

An lvalue is simply something that can appear on the *l*eft side of an
assignment statement, and an rvalue is something that appears on the
*r*ight side of an assignment statement.

It seems trivially obvious, but has far-reaching consequences. For one
thing, to be an lvalue means that you must be able to assign a value to
it. I.e., it must be a variable that exists somewhere in memory; `1 =
x;` is illegal because `1` is a literal with no memory associated with
it, so you cannot assign a new value to it.

For something to be an rvalue means that it's a value like `1` that may
not necessarily have a memory address associated with it. For example,
the value of a computation is an rvalue:

	// This is OK:
	x = y + 1;

	// This is not OK:
	(y + 1) = x;

The value of a computation cannot be assigned to, it makes no sense.
Therefore, given an rvalue, you are not guaranteed that assignment is
legal.

Note however, that given an lvalue, you can always get an rvalue out of
it. In the first example above, `y` can be an lvalue because it's a
variable with a memory location. However, it can also be used as an
rvalue.  Or, if you like, `x = y;` contains an implicit "cast" of y to
an rvalue.  But you can never turn an rvalue back into an lvalue.


T

-- 
It's bad luck to be superstitious. -- YHL