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@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).

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.