On Fri, 26 Oct 2018 at 00:54, Jonathan Wakely <jwak...@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.
