On Thu, 3 Oct 2024 at 10:06, Timon Gehr via Digitalmars-d <digitalmars-d@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@puremagic.com <mailto:digitalmars-d@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.