<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 9 Oct 2024 at 16:09, Jonathan M Davis via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tuesday, October 8, 2024 11:42:49 PM MDT Manu via Digitalmars-d wrote:<br>
> On Sun, 6 Oct 2024 at 14:06, Walter Bright via Digitalmars-d <<br>
> A fix that would simplify the language and the compiler would be to have a<br>
> > unique syntax for a move constructor, instead of the ambiguous one in the<br>
> > proposal. That way, searching for a copy constructor will only yield copy<br>
> > constructors, and searching for a move constructor will only yield move<br>
> > constructors. There will be a sharp distinction between them, even in the<br>
> > source<br>
> > code. (I have seen code so dense with templates it is hard to figure out<br>
> > what<br>
> > kind of constructor it is.)<br>
> ><br>
> > Something like one of:<br>
> > ```<br>
> > 1. =this(S)<br>
> > 2. this(=S)<br>
> > 3. <-this(S)<br>
> > ```<br>
> > ?<br>
> ><br>
> > It may take a bit of getting used to. I kinda prefer (1) as it is sorta<br>
> > like<br>
> > `~this()`.<br>
><br>
> It's not right to distinguish move constructors, by-value argument is a<br>
> potential move opportunity.<br>
> Why aren't the regular parameter matching semantics sufficient? Can you<br>
> please give us a set of examples where the regular parameter matching<br>
> semantics are failing or infinite-looping?<br>
<br>
Aside from whatever Walter's reasoning is, there are existing constructors<br>
in the wild which use<br>
<br>
    this(S)<br>
<br>
to construct a copy of a struct. This allows code such as<br>
<br>
    auto s = S(otherS);<br>
<br>
and<br>
<br>
    auto s = new S(otherS);<br>
<br>
to compile. This is particularly useful in generic code where you're dealing<br>
with a variant type, since without that, you have to either use a static if<br>
branch every time that you construct it in case the variant type is being<br>
passed in, or you have to create the type with a wrapper function that does<br>
the static if for you. By just creating a constructor that specifically<br>
takes the same type (or having a templated constructor which does the<br>
appropriate static if internally), that issue is avoided. And while it can<br>
certainly be argued whether that's the best approach, it's an approach that<br>
exists in the wild today. So, if<br>
<br>
    this(S)<br>
<br>
suddenly becomes a move constructor, existing code will have a normal<br>
constructor suddenly turned into a move constructor.<br></blockquote><div><br></div><div>Hmmmm. Well, that's not and never was a copy constructor... so are we required to accept that that was ever correct code?<br></div></div><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It's already problematic enough that copy constructors don't have an<br>
explicit identifier of some kind (which IMHO really should be fixed).<br></blockquote><div><br></div><div>What kind of problem is a result of copy constructors not having an identifier?</div></div></div>