They initialise an S from another S... I'm not sure what you mean by "they do different things"?

I've been wondering, why do you need to detect that a constructor is a copy or move constructor? That concept seems like a big internal hack. Why do normal overload selection semantics fail to determine the proper selection?
It's not clear why it's useful or important that copy and move constructors are separate from all other constructors? They're not special; they just happen to accept a self-type as an init argument... the only reason I can think, is to identify the case where they're not present, and some copy/move code must by synthesised in lieu... what else hangs off that knowledge?

On Fri, 11 Oct 2024 at 16:11, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
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.