Move Constructor Syntax

[Manu]

On Tue, 15 Oct 2024, 19:56 Arafel via Digitalmars-d, <
digitalmars-d at puremagic.com> wrote:

> On 15/10/24 11:26, Manu wrote:
> > Show me a case study; what might you do with an rvalue constructor if
> > not initialise an instance from an rvalue?
>
> I think one such case might be metaprogramming. Consider:
>
> ```d
> struct S {
>         int i;
>         this(C)(C c) if (is(C : int)) {
>                 this.i = c;
>         }
>
>         alias i this;
> }
>
> void main() {
>         S s1, s2, s3;
>         int i = 1;
>         s1 = S(1);
>         s2 = S(i);
>         s3 = S(s1); // This was most certainly not intended as a move
> constructor.
> }
> ```
>

Your example is a valid move constructor though... so even if the S(S) case
were reinterpreted under the new move semantics, it's fine. It's almost
impossible to imagine such an example where this isn't true.


This example might seem artificial, and it is, but just imagine any
> templated constructor that uses DbI, and where the own type matches.
>
> The actual inner details (i.e. that `S` is instantiated) might be even
> unknown to the caller, for instance if it comes from the user side of an
> API through a templated function using IFTI.
>
> Also, you cannot use `ref` because you want it to accept both r- and
> l-values, and in any case there might be good reasons why this isn't
> desirable in metaprogramming.
>

That's what auto ref is for, if this specifically is your problem... and as
I described before; there's a quite likely chance that instances of this
pattern in the wild were actually written by D amateurs, and the code is
actually broken, or doesn't actually quite do what they think they were
trying to do.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20241016/2ef5e5c2/attachment-0001.htm>