F.45 needs another exception for rvalue overloads

F.45 is titled "Don’t return a T&&" and states:

We don’t know of any other good examples [besides std::move] of returning &&.

This is ignorant of functions such as:

• std::basic_ostringstream::str() && -> std::basic_string&&
• std::optional<T>::value() && -> T&&
• ...

The recommendations of CppCoreGuidelines shouldn't contradict common practice in modern C++ standard library features. One could argue that even the standard library uses are illegitimate and unsafe, and there is truth to that. However, the user would incur unjust cost for code such as:

// if .value() returned a value instead of an rvalue reference,
// this would unnecessarily create a temporary object
vec.emplace(get_optional().value());

The zero-overhead principle, a core design principle of the language from the very start arguably trumps the slight safety benefit of returning a value.

Proposed Changes

-We don’t know of any other good examples of returning &&.

+##### Exception
+Member accessors such as `std::get(std::tuple)`,
+or `std::optional::value()` have overloads for rvalue references,
+and those overloads return rvalue references.
+This is fine because it simply imitates what happens when accessing a member of an rvalue struct,
+or a member of an rvalue array.

Start at the C++ Core Guidelines source entry for rule F.45 and compare its current wording with the proposed exception. Done means the guidance acknowledges rvalue-reference overloads for member accessors such as std::get(std::tuple) and std::optional::value(), with wording consistent with the proposal.