Move Constructor Syntax

[RazvanN]

On Tuesday, 15 October 2024 at 09:33:59 UTC, Manu wrote:
> On Tue, 15 Oct 2024 at 01:56, RazvanN via Digitalmars-d < 
> digitalmars-d at puremagic.com> wrote:
>
>> On Friday, 11 October 2024 at 16:12:39 UTC, Manu wrote:
>> > On Thu, 10 Oct 2024, 17:10 Walter Bright via Digitalmars-d, 
>> > < digitalmars-d at puremagic.com> wrote:
>> >
>> >> On 10/8/2024 10:42 PM, Manu wrote:
>> >> > Can you show us some cases?
>> >>
>> >> I'd get infinite recursion with overload resolution, because
>> >> the compiler
>> >> will
>> >> try and match the argument to `S` and `ref S`, made even 
>> >> more
>> >> complicated
>> >> with
>> >> rvalue references enabled.
>> >>
>> >
>> > I don't understand; was the argument an rvalue or an lvalue?
>> > It is not at all ambiguous or difficult to select the proper
>> > overload
>> > here... one should have been an exact match, the other would
>> > have required
>> > a copy or conversion; making it an obviously less preferable
>> > match.
>> >
>>
>> ```d
>> struct S
>> {
>>      this(ref typeof(this));
>>      this(typeof(this));
>> }
>>
>> void fun(S);
>>
>> void main()
>> {
>>      S a;
>>      fun(a);
>> }
>>
>> ```
>>
>> When the fun(a) is called, the compiler will have to check both
>> constructors to see which one is a better match. It first tries
>> the copy constructor and sees that it's an exact match, then it
>> proceeds to the next overload - the move constructor. Now it 
>> wants
>> to see if the move constructor is callable in this situation.
>> The move constructor receives its argument by value so the
>> compiler
>> will think that it needs to call the copy constructor (if it
>> exists).
>
>
> Isn't this the exact moment that the recursion ends? If the 
> copy ctor was an exact match (we must have been supplied an 
> lvalue), and (therefore) while considering the move constructor 
> it was determined that a copy is necessary, then it is not an 
> exact match... copy ctor wins. Case closed.
>

The way overload resolution works is that you try to call match
each function in the overload set and always save (1) the best 
matching level
up this far, (2) the number of matches and (3)a pointer to the 
best matching function (and potentially a second pointer to a 
second function, provided that
you have 2 functions that have the same matching level). Once 
overload
resolution is done you inspect these results and either pick a 
single
function or error depending on what you get. This works without 
any
special casings (there are minor special casings for unique 
constructors,
but that's fairly non-invasive).

If we were to accept `this(typeof(this))` as a move constructor, 
we would need
to special case the overload resolution mechanism. I'm not saying 
it's not possible to implement, rather that we need to add this 
special case to a
battle tested algorithm.

In contrast, we could leave the overload resolution code 
untouched and simply
give the move constructor a different identifier (what I mean is, 
you type `this(S)`, but internally the compiler gives the 
__movector name to the function). When the compiler inserts calls 
to the move constructor it will then need to do overload 
resolution using the name __movector. This seems to me like a 
more desirable alternative: you get the this(S) syntax (provided 
that Walter accepts the possibility of code breakage or code 
fix-up as you call it) and the overload
resolution code remains intact. Additionally, you get smaller 
overload resolution
penalties given that the overload sets get smaller.

> Now, since the copy constructor is in the same overload
>> set as the move constructor, both need to be checked to see 
>> their matching levels. => infinite recursion.
>>
>> That is how overload resolution works for any kind of function
>> (constructor, destructor, normal function). The way to fix this
>> is to either move the copy constructor and the move
>> constructor into different overload sets or to special case 
>> them
>> in the
>> function resolution algorithm.
>>
>
> Yeah sorry, I just don't see it.
> When the pair are both defined; one is an exact match, and the 
> other is
> not. Given an rvalue, the move ctor is an exact match, given an 
> lvalue, the
> copy ctor is an exact match. There is no case where this is 
> ambiguous?

Before having copy ctors it was allowed to have  this(ref S) and 
this(S)
and it worked. So I don't see any opportunity for ambiguity. 
However, when you
add some implicit constructor calls that's when things get a bit 
messy, however,
that's not an unsolvable problem. It just depends on what sort of 
trade-offs you
are willing to make from an implementation stand point.

RazvanN