Move Constructors - Converting Lvalues to Rvalues

Timon Gehr timon.gehr at gmx.ch
Thu Oct 3 20:45:05 UTC 2024


On 10/3/24 17:35, Walter Bright wrote:
> What if you have:
> ```
> void foo(S);
> void foo(ref S);
> void foo(@move S);
> ```
> ? The overloading rules are already much more complex than I intended.
> ...

Well, as I said elsewhere, I think the first and third overload are just 
ambiguous with each other. They both prefer rvalues, of the same type.

> 
> ```
> S foo(S s)=>s;
> ```
> 
>  > There is actually no reason for this to make a copy, and the compiler 
> would in principle be able to figure it out.
> 
> I did consider it (actually `S foo(ref S s)=>s;`),

Well, with `ref` it does not work because ownership remains with the caller.


> but didn't like it 
> because it would require major changes in multiple places in some 
> already complex code. It was too high risk of introducing all kinds of 
> unexpected interactions and problems. And, in the end, __lvalue(s) does 
> the same thing and is fairly simple.
> 
> I'm also currently struggling with:
> ```
> this(S);
> this(ref S);
> ```
> and then trying to get "is it copyable" to work. The trouble is that a 
> move constructor not only has an S for an rvalue, that S must also be 
> the same as the struct name. This cannot be determined by the parser, it 
> needs semantic analysis. This means that when the constructor is 
> searched for, it has to exclude matching on a move constructor, that 
> cannot be detected before semantic analysis.
> ...

Sounds annoying, but I guess this is a general issue, as metaprogramming 
can be involved in the declaration of constructors.

> The solution will likely be adding another parameter to the name lookup. 
> Sigh, more slowdowns and complexity.
> 
> The __rvalue thing, on the other hand, requires (I think) very little 
> disruption to the compiler and language.

Well, `__rvalue` is fine. The question is just is it really sensible to 
tie move semantics to pass by value, and likely the answer is "not 
really". It is already obvious with the move constructor design.


More information about the Digitalmars-d mailing list