Move Constructor Syntax

[Jonathan M Davis]

On Sunday, October 6, 2024 11:00:16 AM MDT Walter Bright via Digitalmars-d 
wrote:
>  > So, whatever solution we come up with for helping the compiler identify
>  > move
> constructors, I hope we can apply it to copy constructors too.
>
> Sure, but I think that would be a separate proposal.

Sure, but depending on the solution for move constructors, that could affect
what we'd want to do with copy constructors. For instance, if we decide that
we want to make move constructors be

    =this(T t) {...}

maybe that would imply that we want to update copy constructors to be
something like

    +this(ref T t) {...}

But of course, that would mean changing copy constructors. So, if we know
that we want to do something with copy constructors similar to what we're
discussing here with move constructors with regards to reliably identifying
them, then arguably, a solution which didn't require changing the existing
copy constructors would be preferable. So, we might want to take that into
account with what we decide to do with move constructors.

Personally, I'm fine with updating copy constructors to use a new symbol
(with an appropriate deprecation period of course), since the issues that
Paul is talking about have proven to be a real annoyance with copy
constructors. The way that copy constructors deal with attributes and type
qualifiers right now is terrible. But if we want to do that, we should
probably at least partially consider what we want to do with that at the
same time that we work out move constructors so that we can have a clean and
consistent solution that we're happy with - and even if we want to go with
adding a symbol to the front of this like we do with destructors, if we're
going to do that, we should probably think about copy constructors at the
same time, since then we potentially are going to want to do the same to
copy constructors, and then we're talking about adding two symbols to this,
not just =this for move constructors.

- Jonathan M Davis