On 07/10/2024 5:56 AM, Walter Bright wrote:
> On 10/6/2024 2:58 AM, Richard (Rikki) Andrew Cattermole wrote:
>> Does that not have desirable potential additions, once move constructors have been resolved?
>> For now, it can error if seen elsewhere.
> 
> I know you've proposed @move for parameters already, but this seems inconsistent with that.

For parameters yes, I'd prefer that a copy constructor turned into a move constructor wasn't some special thing. But if you really want it to be a different overload set, well do it on the function to define it.

```d
this(ref Thing other) @move {
}
```

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

On 07/10/2024 12:09 PM, Richard (Rikki) Andrew Cattermole wrote:
> On 07/10/2024 5:56 AM, Walter Bright wrote:
>> On 10/6/2024 2:58 AM, Richard (Rikki) Andrew Cattermole wrote:
>>> Does that not have desirable potential additions, once move constructors have been resolved?
>>> For now, it can error if seen elsewhere.
>>
>> I know you've proposed @move for parameters already, but this seems inconsistent with that.
> 
> For parameters yes, I'd prefer that a copy constructor turned into a move constructor wasn't some special thing. But if you really want it to be a different overload set, well do it on the function to define it.
> 
> ```d
> this(ref Thing other) @move {
> }
> ```

There is a very good reason to prefer an attribute rather than new syntax, it doesn't break tooling.

On 10/6/2024 11:20 AM, Lance Bachmeier wrote:
> what's wrong with a clear and simple approach like
> 
> ```
> this(move S)
> ```

It looks similar to Rikki's @move syntax, which is already discussed.


> Any of the three you've proposed would add considerable overhead to someone learning the language.

Unfortunately, a move constructor inevitably adds more to be learned. I don't know a way around that.


> I'm not a fan of even more syntax.

Neither am I. But I failed at finding a way to implement it without more syntax. I tried for several days.

On 10/6/2024 12:00 PM, Anonymous wrote:
> this move(...)
> this copy(...)
> this(...)
> ~this(...)

Not bad, but we already have copy constructors.

On 10/6/2024 10:26 AM, Paul Backus wrote:
> If we adopt `=this` as the move-constructor syntax, what will we use if we decide to add a dedicated copy-constructor syntax in the future?

We haven't needed one yet!

On 10/5/2024 9:04 PM, Walter Bright via Digitalmars-d wrote:
> ```
> struct S { ... }
> 
> this(ref S) // copy constructor
> this(this)  // postblit
> //this(S)     // move constructor
> ~this()     // destructor

Not sure this actually would work well or not, but figured I'd add it to the list for consideration:

this (move S) // move constructor

On 07/10/2024 8:15 PM, Brad Roberts wrote:
> On 10/5/2024 9:04 PM, Walter Bright via Digitalmars-d wrote:
>> ```
>> struct S { ... }
>>
>> this(ref S) // copy constructor
>> this(this)  // postblit
>> //this(S)     // move constructor
>> ~this()     // destructor
> 
> Not sure this actually would work well or not, but figured I'd add it to the list for consideration:
> 
> this (move S) // move constructor

We have had multiple people suggesting something to this equivalence including this specific syntax.

On Monday, 7 October 2024 at 06:41:13 UTC, Walter Bright wrote:
> On 10/6/2024 10:26 AM, Paul Backus wrote:
>> If we adopt `=this` as the move-constructor syntax, what will we use if we decide to add a dedicated copy-constructor syntax in the future?
>
> We haven't needed one yet!

https://forum.dlang.org/post/uvqyfedjuuerueinikwl@forum.dlang.org