<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 12 Oct 2024 at 03:50, 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 Friday, October 11, 2024 10:14:36 AM MDT Manu via Digitalmars-d wrote:<br>
> On Thu, 10 Oct 2024, 17:56 Walter Bright via Digitalmars-d, <<br>
><br>
> <a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br>
> > On 10/8/2024 11:54 PM, Manu wrote:<br>
> > > Hmmmm. Well, that's not and never was a copy constructor...<br>
> ><br>
> > Well, it is. I don't recall when or why it was included in D.<br>
><br>
> It was because postblit was riddled with problems... (maybe there's a<br>
> lesson there?)<br>
><br>
> Anyway, I thought of an issue with separating the constructor into a<br>
> bespoke name; what happens when you do this:<br>
><br>
> =this(S);<br>
> this(S);<br>
><br>
> Which is selected?<br>
<br>
That's very clear. Move constructors simply cannot be explicitly called via<br>
the normal constructor syntax and do not take part in overload resolution.<br>
They have no need to. We already have the move function for moving objects<br>
(and Martin Kinke wants to make it an intrinsic, which makes sense). So, if<br>
you want to do an explicit move, you call move. And for implicit moves, the<br>
compiler knows how to call the move constructor if that's necessary (and it<br>
may be changed to just call the lowering for move as a compiler intrinsic in<br>
order to put all of the move logic in one place).<br>
<br>
So, if you then make an explicit constructor call with an rvalue - e.g.<br>
S(getOtherS()) - then that will only work if you've declared a normal<br>
constructor such as this(S). And if such a constructor exists, and you make<br>
that explicit call with an rvalue, the move constructor would be triggered<br>
just like it would for any other function call that took an rvalue that had<br>
a move constructor, moving the argument into the constructor's parameter.<br>
<br>
In addition, =this(S); should really be changed to =this(ref S); anyway,<br>
because the move has not occurred yet, and the parameter needs to be a<br>
reference to the object that's being passed in. Using ref explicitly avoids<br>
the need for a weird special case with the parameter not being typed as ref<br>
while still actually being treated as ref and not running the destructor<br>
upon exit. And by giving the move constructor explicit syntax, we can put<br>
ref on the parameter without conflicting with copy constructors.<br>
<br>
> What about:<br>
><br>
> =this(S);<br>
> this(T)(T); which overlaps the concrete case?<br>
<br>
It's a non-issue as well, because move constructors simply take no part in<br>
overload resolution and cannot be called like a normal constructor. So,<br>
there's never any ambiguity due to the fact that they exist.<br>
<br>
- Jonathan M Davis</blockquote><div><br></div><div>I don't even know where to start on this whole post... every single sentence is problematic. I'm essentially convinced at this point that:</div><div>1. You don't really know about move semantics; the ideas here are just bad, and you don't seem to know this... I suspect you just have no experience with move semantics, and have no associated expectations or assumptions.<br></div><div>2. Maybe you haven't read the DIP? Either that, or you've totally missed the point, and completely missed the merits of the design; because everything you describe here is in opposition to an efficient and semantically uniform implementation.<br></div><div>3. You're not actually talking about the DIP in discussion...</div><div><br></div><div>
I don't think I have the energy to pull apart each sentence, and I doubt you're interested to hear it anyway. 
Maybe my post on the other thread might help get us on the same page.



</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 12 Oct 2024 at 03:50, 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 Friday, October 11, 2024 10:14:36 AM MDT Manu via Digitalmars-d wrote:<br>
> On Thu, 10 Oct 2024, 17:56 Walter Bright via Digitalmars-d, <<br>
><br>
> <a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br>
> > On 10/8/2024 11:54 PM, Manu wrote:<br>
> > > Hmmmm. Well, that's not and never was a copy constructor...<br>
> ><br>
> > Well, it is. I don't recall when or why it was included in D.<br>
><br>
> It was because postblit was riddled with problems... (maybe there's a<br>
> lesson there?)<br>
><br>
> Anyway, I thought of an issue with separating the constructor into a<br>
> bespoke name; what happens when you do this:<br>
><br>
> =this(S);<br>
> this(S);<br>
><br>
> Which is selected?<br>
<br>
That's very clear. Move constructors simply cannot be explicitly called via<br>
the normal constructor syntax and do not take part in overload resolution.<br>
They have no need to. We already have the move function for moving objects<br>
(and Martin Kinke wants to make it an intrinsic, which makes sense). So, if<br>
you want to do an explicit move, you call move. And for implicit moves, the<br>
compiler knows how to call the move constructor if that's necessary (and it<br>
may be changed to just call the lowering for move as a compiler intrinsic in<br>
order to put all of the move logic in one place).<br>
<br>
So, if you then make an explicit constructor call with an rvalue - e.g.<br>
S(getOtherS()) - then that will only work if you've declared a normal<br>
constructor such as this(S). And if such a constructor exists, and you make<br>
that explicit call with an rvalue, the move constructor would be triggered<br>
just like it would for any other function call that took an rvalue that had<br>
a move constructor, moving the argument into the constructor's parameter.<br>
<br>
In addition, =this(S); should really be changed to =this(ref S); anyway,<br>
because the move has not occurred yet, and the parameter needs to be a<br>
reference to the object that's being passed in. Using ref explicitly avoids<br>
the need for a weird special case with the parameter not being typed as ref<br>
while still actually being treated as ref and not running the destructor<br>
upon exit. And by giving the move constructor explicit syntax, we can put<br>
ref on the parameter without conflicting with copy constructors.<br>
<br>
> What about:<br>
><br>
> =this(S);<br>
> this(T)(T); which overlaps the concrete case?<br>
<br>
It's a non-issue as well, because move constructors simply take no part in<br>
overload resolution and cannot be called like a normal constructor. So,<br>
there's never any ambiguity due to the fact that they exist.<br>
<br>
- Jonathan M Davis<br>
<br>
<br>
<br>
</blockquote></div>