On Tuesday, October 8, 2024 11:42:49 PM MDT Manu via Digitalmars-d wrote:
> On Sun, 6 Oct 2024 at 14:06, Walter Bright via Digitalmars-d <
> A fix that would simplify the language and the compiler would be to have a
> > unique syntax for a move constructor, instead of the ambiguous one in the
> > proposal. That way, searching for a copy constructor will only yield copy
> > constructors, and searching for a move constructor will only yield move
> > constructors. There will be a sharp distinction between them, even in the
> > source
> > code. (I have seen code so dense with templates it is hard to figure out
> > what
> > kind of constructor it is.)
> >
> > Something like one of:
> > ```
> > 1. =this(S)
> > 2. this(=S)
> > 3. <-this(S)
> > ```
> > ?
> >
> > It may take a bit of getting used to. I kinda prefer (1) as it is sorta
> > like
> > `~this()`.
>
> It's not right to distinguish move constructors, by-value argument is a
> potential move opportunity.
> Why aren't the regular parameter matching semantics sufficient? Can you
> please give us a set of examples where the regular parameter matching
> semantics are failing or infinite-looping?

Aside from whatever Walter's reasoning is, there are existing constructors
in the wild which use

    this(S)

to construct a copy of a struct. This allows code such as

    auto s = S(otherS);

and

    auto s = new S(otherS);

to compile. This is particularly useful in generic code where you're dealing
with a variant type, since without that, you have to either use a static if
branch every time that you construct it in case the variant type is being
passed in, or you have to create the type with a wrapper function that does
the static if for you. By just creating a constructor that specifically
takes the same type (or having a templated constructor which does the
appropriate static if internally), that issue is avoided. And while it can
certainly be argued whether that's the best approach, it's an approach that
exists in the wild today. So, if

    this(S)

suddenly becomes a move constructor, existing code will have a normal
constructor suddenly turned into a move constructor.

It's already problematic enough that copy constructors don't have an
explicit identifier of some kind (which IMHO really should be fixed).