LWG 2839 inquiry

I’m working on a string library that wraps std::basic\_string and uses a “rvalue-aware” API pattern:

* const& overload returns a new string
* && overload tries to reuse the existing buffer and returns by value

The intended usage is this kind of chaining:

my_string s = "...";
s = std::move(s).trim();
s = std::move(s).to_lowercase();

I have many cases in which I found performance gains by defining a "create new object" version of a transformation alongside and inplace one and this pattern allows me to reuse method identifiers.


A simplified example looks like this:

struct my_string {
std::string data;

my_string trim() const& {
my_string result;
copy_trimmed_part_to(result); // determine subrange after trim and only copy that part
return result;
}

my_string trim() && {
trim_inplace(); // mutate the current object / reuse buffer
return std::move(*this); // return by value
}

// ...

my_string& operator=(my_string&&) = default;
};

My question is about [LWG 2839](https://cplusplus.github.io/LWG/issue2839), which talks about self-move-assignment.

At first glance, s = std::move(s).trim() feels like it might be related, because the && overload operates on s and then the result is assigned back into s. But the returned object is still a separate prvalue result, even if it reuses the original buffer internally.

So:

1. Is s = std::move(s).trim() actually covered by the self-move-assignment concerns from LWG 2839?
2. Or is LWG 2839 only relevant to direct cases like s = std::move(s)?
3. If the wrapper is built on top of std::basic\_string, is there any subtle standards issue with this API pattern itself?
4. Is the real risk instead overlap/aliasing in APIs like replace, insert, etc. when additional arguments may refer into the same string?

I’m interested both in the strict standards view and in whether this pattern is considered sound library design in practice.

https://redd.it/1tdalnh
@r_cpp