On 10/8/2024 11:08 PM, Manu wrote:
> Can you show some cases where the distinction is necessary?

I tried to in the other post you made.

Recall that C++ had to invent a whole new type to make it work - rvalue references:
```
S(S&&)
```
I wish to avoid that.

On 10/8/2024 11:08 PM, Jonathan M Davis wrote:
> So, if
> 
>      this(S)
> 
> suddenly becomes a move constructor, existing code will have a normal
> constructor suddenly turned into a move constructor.

Yup. Kaboom.

On 10/8/2024 10:37 PM, Imperatorn wrote:
> Just a question, are move semantics out of the question?

???

On 10/8/2024 11:54 PM, Manu wrote:
> Hmmmm. Well, that's not and never was a copy constructor...

Well, it is. I don't recall when or why it was included in D.


> so are we required to accept that that was ever correct code?

Yes. I'm not willing to endure the legions of people saying I broke their code, and the fix for them is not obvious. The way some people use D is terrifyingly (to me) over-complicated with templates and aliases and trampolines and forwards, etc.

So I embarked on "how can I make this as simple and understandable as possible".


> What kind of problem is a result of copy constructors not having an identifier?

Being unable to tell if `this(S)` is a copy constructor or not without semantic analysis.

BTW, with the prototype implementation of move constructors, move constructors get a separate identifier, `__moveCtor`, so it is usable from system code.

The way the symbol table works, and all the overloads and templates, attempting to search all the `__ctor` functions looking for the move constructor is very inefficient.

BTW, every reply you make starts a separate subthread. Can you please fix that?

On 10/10/2024 7:39 PM, Walter Bright wrote:
> On 10/6/2024 5:16 PM, Richard (Rikki) Andrew Cattermole wrote:
>> There is a very good reason to prefer an attribute rather than new syntax, it doesn't break tooling.
> 
> True, but an attribute for constructors only seems rather odd.

Attributes are related to assumptions and guarantees, and the difference between a copy constructor and move constructor is the assumptions that the compiler is allowed to make.

For whatever reason, this feature just keeps giving me the nagging sensation that something isn't right with the motivation.

On Fri, Oct 11, 2024 at 5:36 AM Salih Dincer via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thursday, 10 October 2024 at 09:33:21 UTC, Zoadian wrote:
> > the fact that you have to add comments shows how bad the syntax
> > actually is.
> > imaging having them readable like this instead so one doesn't
> > have to look up the language documentation to figure out what's
> > going on:
> > ```
> > constructor()
> > copy_constructor()
> > blit_constructor()
> > move_constructor()
> > destructor()
>
> I am surprised by suggestions that would break the code just to make it look melodious...
>
> Yes, you are suggesting alternative syntaxes for the move constructor, which does not officially exist in D. These suggestions are quite interesting from a language design perspective and could offer different approaches to usage. Unfortunately, we are not inventing a new programming language. So we can only suggest suggestions that are compatible with the existing one. For technical reasons, `this(S)` will not work.
>
> IMO, there's any need to discussion. We have only one option. Just do it and let's not waste time:
>
> **Move Constructor Syntax: `=this(S)`**
>
> In the upcoming version of D, we are adding a **move constructor** to complement the existing **copy constructor** and **destructor**. Just as destructors are invoked with `~this()`, move constructors will now be expressed using the intuitive and concise syntax `=this(S)`.
>
> The `=this(S)` move constructor enables efficient transfer of resources from one object to another without the overhead of copying. When an object is moved, its internal resources (such as memory pointers) are transferred to the new object, and the original object is left in a safe, "moved-from" state, often with nullified or reset values.
>
> **Why =this(S)?**
>
> **Symmetry with Destructor:** Just like the destructor `~this()`, which frees up resources, the move constructor `=this(S)` transfers ownership of resources. This symmetry makes the syntax easy to understand and use.
>
> **Efficiency:** Moving objects is more efficient than copying because it avoids unnecessary memory allocations or deep copies. In the move constructor, resources are transferred directly, leaving the original object in a state where its resources can safely be discarded.
>
> Don't you want to have what is written above? Let's increase the performance as soon as possible because this has gone on for too long! I have another question at this stage:
>
> **Question About How Destructors and Move Constructors Work Together:**
>
> Since the original object is invalidated, does the destructor
> (`~this()`) know that it has nothing to free when it is called on
> the moved object?
>
> SDB@79
>

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.

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

On 10/10/2024 11:57 AM, Richard (Rikki) Andrew Cattermole wrote:
> For whatever reason, this feature just keeps giving me the nagging sensation that something isn't right with the motivation.


Something I overlooked. With the original plan,
```
this(ref S) // copy constructor
this(S) // move constructor
```

Generally speaking, functions that are overloaded should do the same thing, just with different arguments. But the copy and move overloads do something quite different. This is difference is what has been causing me frustrating problems with implementing it.