Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve reasoning and examples for F.48 #2100

Merged
merged 3 commits into from
Apr 11, 2024
Merged

Conversation

Eisenwave
Copy link
Contributor

With guaranteed copy elision, it is now almost always a pessimization to expressly use std::move in a return statement.

The reasoning in F.48 is misleading because it only refers to guaranteed copy elision, but the example listed underneath shows NRVO, for which this elision is not guaranteed.

I think it the reasoning is much better if it is made clear to the reader that a return statement will always move local variables. It is also helpful to distinguish between RVO and NRVO in the example, as the two have optimization differences.

{
S result;
return std::move(result);
}

##### Example, good

S f()
// RVO: guaranteed move elision when a temporary is returned
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

language lawyers will argue that C++17 prvalue return is not an optimization and so not "RVO"
Perhaps omit it and just focus on returning local variables?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, the standard doesn't call it RVO or NRVO, it only says that returning is copy-initialization of the returned object. Nested prvalue initializations like T(T(T(T(...))))) are just elided to one T().

I think it would be best to remove the explicit mention of RVO and NRVO from the diff, but keep the rest of the comment.

Copy link

@MattBelanger321 MattBelanger321 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good Stuff

@hsutter
Copy link
Contributor

hsutter commented Jan 18, 2024

Editors call: Thanks! We like the PR with Sergey's suggested change, Sergey please make it and merge.

@cubbimew cubbimew merged commit c91ea43 into isocpp:master Apr 11, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants