Move Constructor Syntax

[Manu]

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.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20241015/307b86c6/attachment.htm>