Move Constructor Syntax

[ShadoLight]

On Wednesday, 16 October 2024 at 12:00:03 UTC, Arafel wrote:
> On 16.10.24 12:39, ShadoLight wrote:
>> unlike Walter/Timon/Razvan/Manu/<add others> I'm also no 
>> language design guru but, in the above case:
>> 
>> - s1 is an lvalue, so shouldn't a copy ctor be implicitly 
>> generated by the compiler (like in C++)..?
>> - ... and be preferred in this case?
>> 
>> Something like:
>> ```d
>>      S s1, s2, s3;
>>      s1 = S(1);       // this (int i)
>>      s2 = S(s1);      // this (ref S s)  -> implicit
>>          s3 = S(S(2));    // this (S s)
>>          // ...and s1 is valid here
>> ```
>
> That would make sense, but this would in turn mean that the 
> move constructor can never be invoked explicitly.

What do you mean?
    s3 = S(S(2));
...is invoking the move constructor explicitly.

>
> This might well be a design goal, but, in any case, I think 
> that the explicit usage of constructors with a move constructor 
> signature should be specified and clarified as part of the 
> (eventual) DIP.

Agreed.

>
> Also, it wouldn't change the fact that perhaps a struct might 
> need at the same time a move constructor, a copy constructor, 
> and a templated constructor that could overlap any or both of 
> these.

Agreed. But I wonder if some form of precedence may help? AFAICS 
it would be safe(r) if a copy ctor is always preferred to a move 
ctor - also in the case if a templated constructor can resolve to 
either.

For example, in Razvan's infinite recursion example, I wonder if 
it can work if, as Razvan explained, it tries the copy 
constructor 1st and sees that it's an exact match, then simply 
stop any further matching and do copy construction. I mean, are 
any other matches (besides a move constructor) even possible if 
the copy constructor was a _perfect match_ in the 1st place? 
Templated constructors may complicate this but, again, just 
prefer copy construction if any ambiguity.

>
> I'd be all for considering all templated constructors as 
> "normal", even if their signature in a given instantiation 
> would match that of a copy or move constructor.

Agreed.