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

[Jonathan Wakely]

On 30/10/18 07:48 +0100, François Dumont wrote:
>On 10/27/18 12:33 AM, Ville Voutilainen wrote:
>>On Sat, 27 Oct 2018 at 01:27, Joe Buck <joe.buck@synopsys.com> wrote:
>>>The reason move constructors were introduced was to speed up code in cases where an object
>>>Is copied and the copy is no longer needed.  It is unfortunate that there may now be code out
>>>there that relies on accidental properties of library implementations.  It would be best if the
>>>Implementation is not constrained.  Unless the standard mandates that, after a string is moved,
>>>the string is empty, the user should only be able to assume that it is in some consistent but
>>>unspecified state.  Otherwise we pay a performance penalty forever.
>>>
>>>If the standard explicitly states that the argument to the move constructor is defined to be
>>>empty after the call, we're stuck.
>>It certainly doesn't specify so for an SSO string, so we're not stuck.
>>On the other hand, we already get
>>a speed-up, it's just not as much of a speed-up as it can be. What I
>>really loathe is the potential implementation
>>divergence; it's all good for the priesthood to refer to the standard
>>and say "you shouldn't have done that", but
>>that's, as a good friend of mine provided as a phrasing on a different
>>manner, spectacularly unhelpful.
>>
>+1 to allow moved-from strings to be non-empty
>
>In many cases move will take place on temporary instances which future 
>is just to be destroyed.
>
>It's already too bad that in such situation we sometimes do some 
>allocation because current implementation do not support none 
>(std::deque)
>
>Note that on vector we already have this undefined behavior within 
>libstdc++ itself. On std::vector move constructor empty the moved 
>instance but allocator extended one with equal allocator instance 
>don't, it just swap content.

But the content of the new object being constructed is empty, because
it's a new object being constructed. It doesn't have any elements. So
if you swap the content, the moved instance becomes empty. Or have I
misunderstood what you're saying?

>I'll add to my TODO to detect this kind of invalid usage in Debug 
>pendantic mode.

I'm not sure we want to do that; code relying on it might be
non-portable, but it's not undefined.