Move Constructor Syntax

[Jonathan M Davis]

On Thursday, October 10, 2024 5:35:56 PM MDT Danni Coy via Digitalmars-d 
wrote:
> My problem with =this(S) is that from a linguistic point of view it's
> ambiguous. the = could just as reasonably apply to any type of constructor.
> As a new user of the language the only way you can figure out what it does
> is to read the documentation and memorise. That's something you want to
> avoid when creating new syntax if at all possible.

I won't claim that the proposed syntax is intuitive or that it's necessarily
our best choice, but ~this isn't intuitive either (and plenty of programmers
are perfectly fine with it), and the reality of the matter is that you
always need to study up on a new language to understand its syntax. As much
as we want the syntax to be intuitive so that it's easier to learn and
remember, assuming that you understand exactly what a new language does with
its syntax without reading the documentation or a book on the subject or
whatnot is just begging to have issues.

The bigger issue here is if the syntax is hard to remember, and right now,
the only other similar syntax that you'd have to worry about would be ~this,
so it's not much of a problem IMHO. That being said, if we fix copy
constructors to be consistent with move constructors, and they get their own
syntax, then we have a third piece of pretty arbitrary constructor-related
syntax to remember, which is definitely not ideal.

If we do go with something else for move constructors, I would expect it to
be @move, because that would be by far the most straightforward and
consistent given what we currently have in the language, though Walter
clearly is not in favor of it. Either way, naming move constructors
something other than this is highly unlikely to happen, because that's what
D uses for constructors. It's just a question of how we decorate move
constructors to distinguish them from other constructors with a similar
signature. And there's certainly no way that we're going to rename
constructors in general at this point even if we all agreed that this was a
bad name for them (and I really don't think that you're going to find
general agreement on that point, much as you might find a few people who
agree). Using this has worked quite well for us, and even if it did have
some significant problems, it would break too much code for too little gain
to rename constructors now.

- Jonathan M Davis