Move Constructor Syntax

[Jonathan M Davis]

On Friday, October 11, 2024 1:25:53 AM MDT Manu via Digitalmars-d wrote:
> > Aside from whatever Walter's reasoning is, there are existing constructors
> > in the wild which use
> >
> >     this(S)
>
> I had a moment to think on this case you present.
> It's not clear to me how it actually works now; but I think it would be
> interesting to explore that first; because I think the solution for this
> case being reinterpreted as move-constructor is related (and equally
> solved).
>
> This function receives it's arg BY-VALUE; so it can happily accept an
> r-value... but it's not actually clear how this function receives an lvalue
> even in today's language?
> In order for this function to receive an l-value by-value, it must first
> make a copy to supply as the function's argument (but the function is
> allowed to internally mutate its argument)..
>
> ...but isn't *this* said to be the copy constructor?
>
> This already looks like a chicken/egg problem in today's language... how
> does it create a copy of an lvalue to pass the argument to this function
> without calling this function?
> Whatever answer exists that makes this work equally makes the case work
> where this is reinterpreted as a move-constructor.
>
> The only explanation I can imagine is; because this ISN'T actually a copy
> constructor, the compiler determined that it was appropriate to synthesise
> one (which would be to just copy all members), and so an implicit copy
> constructor DOES actually exist beside this constructor, you just didn't
> write it.
> And assuming that's the case, when this becomes reinterpreted as a move
> constructor, the code remains perfectly correct!
>
> I don't see how elevating this declaration to a move-constructor actually
> changes the semantics at all... I don't think it does? I think this
> function ALREADY IS A MOVE CONSTRUCTOR (at least; it's an
> rvalue-constructor, which is the same thing from a semantic perspective);
> it's just working with an inefficient calling convention.
> Move semantics as proposed simply improve this code, no?

No, as far as the language is concerned, it's not a copy constructor, but it
also isn't necessarily a move constructor. In the case that I've described,
it might work as a move constructor, but there's no guarantee that all
constructors with that signature would. Also, the constructor is question is
likely to be a template, which will then probably not play well with what
Walter is trying to do (e.g. copy constructors can't currently be templated,
because that doesn't work unless copy constructors have a unique syntax,
which they don't). As Razvan explained in this thread, in order for copy
constructors (or move constructors) to be allowed to be templates, they
really need a distinct syntax, otherwise the compiler can't know that they
are in fact copy constructors or move constructors until they're
instantiated, which causes a variety of issues.

Honestly, as a user, I see _zero_ benefit in trying to treat either copy
constructors or move constructors like they're normal constructors. They are
treated as special by the compiler in a variety of ways, and I want them to
be visually distinct so that it's clear that they exist. It would also be
nice if the compiler gave me an error when I screwed up a copy constructor
or move constructor in a way that it wouldn't work as one for whatever
reason (e.g. getting ref wrong by accident). A big part of the problem with
the current copy constructors is that it really isn't easy to see at a
glance which constructors are copy constructors. And the fact that they
can't be templated is a _huge_ problem, particularly with regards to
attributes.

While the syntax =this() isn't necessarily great (personally, I'd probably
just vote for using @move for move constructors and then change it so that
copy constructors should have @copy), I see nothing but problems from not
making copy and move constructors distinct and obvious.

- Jonathan M Davis