<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 17 Oct 2024, 07:36 Timon Gehr via Digitalmars-d, <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/16/24 22:06, Arafel wrote:<br>
> On 16/10/24 20:21, Timon Gehr wrote:<br>
>> Yes, I think the sane design is that if you pass an lvalue to an <br>
>> rvalue parameter, that results in a copy (during argument passing), <br>
>> and the copy is destroyed when it goes out of scope in the constructor.<br>
>><br>
>> So if you explicitly call an rvalue constructor, that would behave the <br>
>> same as previously.<br>
>><br>
>> Even with the unamended DIP1040, I think assertion failures would not <br>
>> fire in your example. The way DIP1040 might break such code is if `S` <br>
>> has a destructor.<br>
> <br>
> I guess that would be workable iff templated constructors are excluded <br>
> from being considered move constructors, otherwise there could be cases <br>
> where a move constructor is found that was never meant as such.<br>
> ...<br>
<br>
I guess the question is what else could `S(s)` reasonably do for a `S <br>
s;`. Whether templated or not.<br>
<br>
> Would a way of explicitly requesting a move, like `__rvalue`, be <br>
> available in case the compiler's detection mechanism of last use needs <br>
> to be overridden?<br>
> ...<br>
<br>
Yes, such mechanisms would still be needed. It is an important point as <br>
it is easy to think move semantics just means move constructors, but it <br>
is more than that. Perfect forwarding for rvalues is important too.<br>
<br>
> All in all, I still see no such big benefit in changing the meaning of <br>
> existing valid code, when adding new syntax would be much clearer all <br>
> around.<br>
> ...<br>
<br>
I agree with Manu's reasoning why having `this(ref S)` and `this(S)` <br>
work as "initialization from lvalue" and "initialization from rvalue", <br>
corresponding to copy and move respectively would be cleaner.<br>
<br>
But overall I don't have a strong preference, as dedicated syntax also <br>
has some benefits. The thing I think is most important is getting the <br>
semantics right.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Special-casing the constructor is just admitting that the overload selection mechanics are broken for **all other function calls**... It's not a matter of 'preference'; if the overload mechanics work properly then special casing the constructor wouldn't even be thinkable or raised in conversation. It's a hack; a really dumb hack which just leaves EVERY OTHER FUNCTION broken.</div><div dir="auto"><br></div><div dir="auto">The fact you have "no strong preference" surprises me, maybe I've misunderstood some way in which this is not a hack that's totally broken? Can you explain to me how every other function call isn't broken under the special-case-for-move-constructor solution? Overload selection has to work, it is basically the meat of this whole thing... there's not really anything else to it.</div><div dir="auto"><br></div><div dir="auto">Broken calling semantics for every function other than the constructor is not a 'compromise', it baffles me that people would even consider it.</div><div dir="auto">I mean, you don't 'call' constructors so often, but you do call everything else.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>