Why is std::string's member operator= not lvalue ref-qualified

Question

I recently learned that member functions can be ref-qualified, which allows me to write

struct S {
    S& operator=(S const&) & // can only be used if the implicit object is an lvalue
    { 
      return *this; 
    }
};

S operator+(S const &, S const &) { 
  return {}; 
}

thereby preventing users from doing things like

S s{};
s + s = S{}; // error

However, I see that std::string's member operator= does not do this. So the following code compiles with no warnings

std::string s;
s + s = s;

Is there a reason for allowing this?

If not, would it be possible to add the ref-qualifier in the future, or would that break existing code somehow?

Answer 1

Likely, the timing plays a role in this decision. Ref-qualified member functions were added to the language with C++11, while std::string has been around since C++98. Changing the definition of something in the standard library is not something to be undertaken lightly, as it could needlessly break existing code. This is not a situation where one should exclusively look at why this weird assignment should be allowed (i.e. look for a use-case). Rather, one should also look at why this weird assignment should be disallowed (i.e. look at the benefits, and weigh them against the potential pain when otherwise working code breaks). How often would this change make a difference in realistic coding scenarios?

Looking at the comments, a counter to one proposed use-case was "They could just [another approach]." Yes, they could, but what if they didn't? Proposing alternatives is productive when initially designing the structure (std::string). However, once the structure is in wide use, you have to account for existing code that currently does not use the alternative. Is there enough benefit for the pain you could cause? Would this change actually catch mistakes often enough? How common are such mistakes in contexts where another warning would not be triggered? (As one example, using assignment instead of equality in the conditional of an if statement is likely to already generate a warning.) These are some of the questions with which the language designers grapple.

Please understand that I am not saying that the change cannot be done, only that it would need to be carefully considered.

Answer 2

It cannot be certain why standard does not prohibit behaviour that you presented but there are a few possible explanations:

1. It is simply an overlook in C++11. Before C++11 there was no ref-qualified methods and so someone has forgotten to change the bahaviour in standard.

2. It is kept for backward compatibility for people who were using 'dirty' code like:

std::string("a") = "gds";

for some strange reasons.

And about adding this in future - it would be possible. But first the old operator= would have to become deprecated and later on removed because it would cause code like the one above to not compile. And even then some compilers would probably support it for backward standard compatibility