<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 13 Oct 2024, 08:01 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/12/24 10:06, Manu wrote:<br>
> <br>
>     4. rvalue constructors exist and are used, and are NOT move constructors<br>
> <br>
> <br>
> They are rvalue constructors; it doesn't matter what they do, their <br>
> selection criteria remains identical.<br>
<br>
Just as long as the semantics of the actual declaration does not change. <br>
DIP1040 proposed to change the semantics of the move constructor <br>
declaration itself.<br>
<br>
Anyway, I agree that a clean design may be that a constructor that <br>
accepts an lvalue of the same type should be a copy constructor and a <br>
constructor that accepts an rvalue of the same type should be a move <br>
constructor (templated or not). Without any special semantics of the <br>
declaration itself.<br>
<br>
Then standard overload resolution (with an after-the-fact check whether <br>
there is `ref` on the first parameter) can be used to check whether <br>
something is copyable or moveable.<br>
<br>
<br>
I guess one change in behavior is that code that previously worked with <br>
implicit compiler-generated moves or explicit moves will now invoke <br>
something that had been written as an rvalue constructor, which also <br>
precluded there being any user-defined copy constructor in the struct or <br>
its fields (disabled or otherwise).</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, that's the case in question. We need to see some case studies; I have a suspicion that much code that makes sense and is not actually a bug is actually already some kind of move constructor. </div><div dir="auto">The calling rules choosing a compiler-generated move or an rvalue constructor are murky (because they are both perfect match; there much be a hard coded tie-breaker, and it must be circumstantial), and I bet any code that uses that is brittle and subject to very special care when handling.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"></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">
I am not sure for what purpose rvalue constructors are even being <br>
written today, but I think the only way to invoke them is as an explicit <br>
`S(s)`.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Maybe, and that might be the definition of the hard-coded tie-breaker rule I described a moment ago... It's non-uniform in any event, a complete surprise that there would be 2 separate cases.</div><div dir="auto"><br></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">If someone does something funky in such a constructor, it may <br>
not actually do the right thing if it suddenly starts being called for <br>
moves.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Maybe. Let's find out!</div><div dir="auto">I wouldn't worry about it... It's already a bad API pattern that depends on weird and brittle rules.</div><div dir="auto"><br></div><div dir="auto">What the hell could it reasonably mean to initialise an S from another S and not be some kind of move when written in your code exactly the way you expect a move to appear?</div><div dir="auto">I think if we find examples in the wild either a) it's already a move in waiting, or b) it's actually broken and the author didn't realise. </div><div dir="auto"><br></div><div dir="auto">My bet is that instances of this code were written by inexperienced D programmers who probably had a poor understanding around the semantics of what they wrote. </div><div dir="auto"><br></div><div dir="auto">But let's find out! We need case studies relating to this super weird and frankly nonsense pattern. </div><div dir="auto">In any event, if this is the only breaking change we encounter, then we're in amazingly good shape!</div><div dir="auto">I will submit the PR to correct every project that suffers from this myself...</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>