id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
11684,boost::string_ref lack of move constructor prevents efficient use in some stl containers,banks@…,No-Maintainer,"Not quite sure if this is a bug or a feature request given the statement in the docs:

""string_ref does not define a move constructor nor a move-assignment operator because copying a string_ref is just a cheap as moving one.""

While that line makes total sense on it's own, it does have some undesirable (for me at least) consequences.

It means that and class that may want to have `string_ref`s as members also can't be trivially move constructible even if their other members are expensive to copy.

For custom classes that can be worked around by defining a move constructor that copies the `string_ref` members and moves the rest. But it's a limitation that can't be easily worked around for things like `std::pair` or `std::tuple` since even if you try specialising those templates, you can't redefine the explicitly defaulted move constructor.

This is especially an issue for using `string_ref` as a key or value type in an associative container - in this case the `std::pair` type MUST be copied during insertion. If the other type in the pair is expensive to copy then `string_ref`s lack of move construction becomes an annoying performance barrier.

Workarounds exist so it's hardly high priority, but it does reduce the reusability of `string_ref` and cause there to be cases where an alternative implementation might be used for essentially the same purpose to work around this issue. the cost of adding move construction seem low to me even if it might result in uninformed users using it spuriously under the assumption it will provide some performance increase over copying.

To be clear the request is: '''please consider adding move constructor/assignment to''' `boost::string_ref`.",Feature Requests,closed,To Be Determined,utility,Boost 1.59.0,Optimization,fixed,,