Move Constructors - Converting Lvalues to Rvalues

[Walter Bright]

On 10/2/2024 4:17 PM, Manu wrote:
> your __rvalue() is essentially the `T move(ref T)` intrinsic we discussed at 
> length; so why not just make the move intrinsic rather than this thing?

My original plan was to do just that:
```
S move(ref S s) => s;
```
would be recognized and replaced with the `__lvalue(s)`. What bothered me about 
it was the magic behavior of it, such as what happens with:
```
S move(ref S s, int i) => s;
```
which will behave completely differently, and may be quite surprising to users. 
I expect somebody will inevitably set at store on:

```
S move(ref S s) => s;
S move(ref S s, int i) => s;
```
doing the same thing, but they don't, and the user will be baffled and I will 
get bug reports and the language will become more complicated is in the ugly way 
C++ became.


> 'move' is the operation we seek, and it has 
> lifetime related semantics involved with the operation. __rvalue() doesn't feel 
> like the right abstraction for that set of semantics; you're gonna find yourself 
> wondering where to pin the lifetime semantics in the future...

__rvalue() does nothing more than say its argument is not an lvalue, so it will 
not match with a `ref` parameter. Lifetime analysis occurs after overload 
resolution, so I don't think it will impact it.

__rvalue() is not a move, it just guides the overload resolution to the move 
constructor/assignment. It's a hint.