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.