On 17/10/2024 11:13, Giuseppe D'Angelo wrote:
Hello,

Il 17/10/24 06:32, François Dumont ha scritto:
As a side note you should provide your patches as .txt files so that any
email client can render it without going through an editor.

Apologies for that. Do you mean I should use text/plain attachments instead of text/x-patch?

No, just use .txt extension for your patch. If you have it on your system you should also use git-send-email.




And regarding the patch, I wonder what the std::move is for on the
returned value ?

Like this one:

+    {
+      return std::move(__lhs.append(__rhs));
+    }

As it's a C&P the question might not be for you Giuseppe.

Well, I'll gladly give it a shot. :) I'm assuming you're talking about the operator+(string &&lhs, const char *rhs) overload, whose implementation I copied for operator+(string &&, string_view)?

By spec https://eel.is/c++draft/string.op.plus#2 it must do:

lhs.append(rhs);
return std::move(lhs);

The call to std::move in the specification is likely a pre-C++20 remnant, before the adoption of P1825, which made lhs "implicitly movable". So in principle right now you could just write:

lhs.append(rhs);
return lhs;

Before P1825, `return lhs` would've caused a copy of `lhs`, not a move, even if `lhs` is a variable with automatic storage of type rvalue reference.

In C++23 this area has been further modified by P2266.

In any case both papers are new features, and are not to be treated as DRs. Therefore, since this operator+ overload's code has to be compatible with pre-C++20 semantics (the code is from C++11), the call to std::move must be left in there.¹

The behaviour described by the current wording can also be achieved by

return std::move(lhs.append(rhs))

(the actual implementation in libstdc++), because lhs.append returns a reference to lhs;

I had miss this part.

Thanks for explanation,

François


Reply via email to