Re: RFC: Allow moved-from strings to be non-empty

[Ville Voutilainen <ville dot voutilainen at gmail dot com>]

On Fri, 26 Oct 2018 at 00:54, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> When an SSO string is contained in the small string buffer or has an
> unequal allocator a move operation performs a copy, leaving the original
> data in the moved-from string. Setting the length of the moved-from
> string to zero is not required, so we can avoid two writes (to the
> length member and to set the first character to nul) by leaving the
> moved-from string unchanged.
>
> This might be surprising to some users, who (wrongly) expect a string
> to always be empty after a move. Is that acceptable?
>
> It's worth noting that the current behaviour, where we do more work
> than required, also surprises some people, e.g.
> https://stackoverflow.com/q/52696413/981959
>
> Some tests need to be adjusted due to the new behaviour, but they have
> comments saying they're testing specific implementation details, so I
> don't think needing to adjust them is an argument against making the
> change:
>
> // NOTE: This makes use of the fact that we know how moveable
> // is implemented on string (via swap). If the implementation changed
> // this test may begin to fail.
>
>
> Should we make this change?

I would rather not introduce a behavioral difference between us and
libc++. It does slightly concern me that some users might
actually semantically expect a moved-from string to be empty, even
though that's not guaranteed, although for non-SSO cases
it *is* guaranteed.