You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
F.45 is titled "Don’t return a
T&&
" and states: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:
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
The text was updated successfully, but these errors were encountered: