Move Constructors - Converting Lvalues to Rvalues

[Timon Gehr]

On 10/3/24 02:22, Manu wrote:
> On Thu, 3 Oct 2024 at 10:06, Timon Gehr via Digitalmars-d <digitalmars- 
> d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
> 
>     On 10/3/24 01:07, Manu wrote:
>      > On Thu, 3 Oct 2024 at 03:21, Walter Bright via Digitalmars-d
>      > <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>
>     <mailto:digitalmars-d at puremagic.com <mailto:digitalmars-
>     d at puremagic.com>>> wrote:
>      >
>      >     On 10/1/2024 1:15 PM, Timon Gehr wrote:
>      >      > I guess the new implementation you have in mind is
>     something like
>      >     the following?
>      >      >
>      >      > ```d
>      >      > auto move(T)(ref T arg)=>__rvalue(arg);
>      >      > ```
>      >
>      >     Not exactly. __rvalue would also convert an rvalue to an rvalue.
>      >
>      >
>      > -preview=rvaluerefparams addresses this; it allows an rvalue to be
>      > supplied to the lvalue there. It's actually an essential mechanic to
>      > this whole thing, because it will allow the appropriate selection of
>      > copy/move overloads where a type may define either one, or both.
>     If a
>      > copy and/or move constructor exists, it needs to select the
>     proper one,
>      > and the -preview handles that properly as is.
> 
>     `-preview=rvaluerefparam` allows you to treat an rvalue as an lvalue
>     implicitly in some contexts.
> 
>     `__rvalue` allows you to treat an lvalue explicitly as an rvalue, so it
>     will be moved.
> 
>     I fail to see how those are related.
> 
> 
> __rvalue() needs to be callable with an lvalue or an rvalue.
> That's the only specific interaction on this matter, but beyond that 
> with respect to move semantics in practice; in your application, you 
> will encounter types with copy and/or move constructors/assign 
> operators, general overloads, etc... you need to be able to pass the 
> values that you have and your code needs to work without friction.
> If there is a copy constructor and no move constructor for instance 
> (very common situation) and you pass an rvalue, the code needs to 
> compile. Later if you add a move constructor, it will automatically 
> select that as the appropriate choice.

Well, I think you can interpret this as overload resolution between a 
`ref` and non-`ref` overload as well, which is a bit more powerful 
because the callee can actually determine which one it was. Don't get me 
wrong, I like `-preview=rvaluerefparam`, but I don't think it helps or 
hurts us here.