Move Constructor Syntax

[Walter Bright]

On 10/11/2024 12:06 AM, Manu wrote:
> If the overload resolution rules don't prefer an exact match over a conversion, 
> then something is very wrong with the overload selection rules. What situations 
> cause those waters to become murky?

The difference between an rvalue and lvalue is murky, for one. For example,

1. rvalues can be passed by ref under the hood, even though there's no `ref`

2. lvalues can match both a ref and a non-ref parameter

3. rvalues can implicitly convert to lvalues with -preview=rvaluerefparam

4. rvalue constructors exist and are used, and are NOT move constructors


> The fact you're talking about a separate constructor type to identify the move 
> case leads me to suspect that the rvalue semantic only applies to the argument 
> to that particular function and nothing else?

It's that rvalue constructors already exist and are in use.

> That's not really "move semantics", that's just a move constructor... and I 
> think I've completely misunderstood your DIP if this is correct?

You understood the DIP. I did not - it's unimplementable as it stands because of 
the existing semantics.


> I don't feel like I have these problems in C++, which is far less constrictive. 

C++ has rvalue references and universal references. They never cease to confuse me.

https://isocpp.org/blog/2012/11/universal-references-in-c11-scott-meyers

> I have no way to know or assess whether any of the arrangements of rules you 
> considered or tried actually arrange into a nice tight lattice or not... or if 
> they were generally cohesive and well-formed. We're expected to accept that you 
> tried every possible reasonable arrangement and conclusively determined that 
> it's not workable. I have no idea how we can assess that for reality or not... :/

You're starting from a blank sheet of paper. I'm trying to fit it into the 
existing semantics without breaking existing semantics and complicated user code.