> On Aug 18, 2025, at 7:32 AM, Ben Crowhurst via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Monday, August 18th, 2025 at 1:52 PM, Simon Schröder via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>> On 18. Aug 2025, at 13:56, Bo Persson via Std-Proposals std-proposals_at_[hidden] wrote:
>>
>>> On 2025-08-18 at 13:18, Andrey Semashev via Std-Proposals wrote:
>>>
>>>> On 18 Aug 2025 13:33, Ben Crowhurst via Std-Proposals wrote:
>>>>
>>>>> There is a history of STL implementations introducing string
>>>>> optimisations, for example, copy-on-write in GCC (<=4), adoption of
>>>>> small string optimisation (SSO) - with varying details across GCC,
>>>>> Clang, and MSVC.
>>>>>
>>>>> Focusing on SSO, using std::string, along with std::string_view and move
>>>>> semantics, introduces a frustrating folly.
>>>>> Why? What is the problem with SSO?
>>>
>>> If you get a string_view to a string, and then move the string, the string_view may, or may not, move along - all because of SSO.
>>
>>
>> If you have a string_view or a span to a moved from object there is no reason to believe that the view/span is still valid. It is at least implementation defined behavior if not undefined behavior. If the view still works after a move you just got lucky. It is quite similar for iterators to be invalid for some containers after certain operations on the container.
>>
>> This is certainly not a reason to disallow SSO. If you need a string+string_view with a specific behavior you should implement your own. (Hopefully compatible/convertible to a std::string.)
>>
>
> I'm not pushing back on SSO; the discussion was geared towards formalising the behaviour under a specific container type, i.e. std::small_string. Allowing std::basic_string to be, as many consumers assume, a wrapper around a C-style pointer.

I’m not sure how or why they would think that: they know it is resizable, the know it has an O(1) length.

What you appear to be complaining about is that if you move a std::string, just as when you move a std::vector, or anything else, the content of the source is UB, but in some cases that content is “still” a valid string. But it’s not. Once you have moved a string, the source is definitionally gone, and the fact that it may have the old data present is irrelevant. On many platforms you get the same behavior from delete and free.

A string_view is no different from a span pointing to a vector: Both become invalid after a move or resize (sans reserved capacity rules).

The only way that you can observe the SSO is through incorrect code.

—Oliver