Skip to content

[class.copy.elision] No implicit moves for reference return types #4842

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.

Sign up for GitHub

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

[class.copy.elision] No implicit moves for reference return types #4842

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
35b7548
[class.copy.elision] Use \keyword
jensmaurer Aug 26, 2021
ba8372a
[class.copy.elision] No implicit moves for reference return types
jensmaurer Aug 29, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions source/classes.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6192,12 +6192,14 @@
In the following copy-initialization contexts,
a move operation is first considered before attempting a copy operation:
\begin{itemize}
\item If the \grammarterm{expression} in a \tcode{return}\iref{stmt.return} or
\item If the \grammarterm{expression}
Copy link
Contributor

@xmh0511 xmh0511 Aug 27, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

It seems we also should give that restriction to lambda-expression

[]()->A&{
  /*....*/
};

In this example, the return type is a reference type. Anyway, I think we could uniformly restrict the return type to be an object type in this bullet. Since the return type of a coroutine is always an object type as per [coroutine.traits.primary#1]. In both the function that is non-coroutine and a lambda-expression, they all should be restricted for their return type.

If the expression in a return ([stmt.return]) or co_­return ([stmt.return.coroutine]) statement is a (possibly parenthesized) id-expression that names an implicitly movable entity declared in the body or parameter-declaration-clause of the innermost enclosing function or lambda-expression whose return type shall be (possibly cv-qualified) class type.

If the first overload resolution fails or was not performed

It seems the overload resolution always performs even though the candidate set is empty.

Copy link
Member Author

Choose a reason for hiding this comment

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

The first overload resolution is not performed if we don't have an implicitly movable entity to start with.

Copy link
Contributor

Choose a reason for hiding this comment

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

According to the whole rule, it is based on we do have an implicitly movable entity. Since it says as if the expression or operand were an rvalue. Since we have such a expression or operand, the overload resolution definitely performs.

Copy link
Member Author

Choose a reason for hiding this comment

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

No.

p1 talks about copy/move elision, which is totally different.

p3 talks about trying a move under certain circumstances; p3 starts with the definition of implicitly movable entity. Then, it says "In the following situations, a move is considered before attempting a copy". If e.g. the "return" is returning a global variable, this is not one of those situations, and we never try a move. We always try a copy, though.

Copy link
Member Author

Choose a reason for hiding this comment

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

Reworded to cover both functions and lambda-expressions.

Copy link
Contributor

@xmh0511 xmh0511 Aug 30, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

If we phrase it as the following, it seems more clear

if the expression or operand is an implicitly movable entity, overload resolution to select the constructor for the copy or the return_­value overload to call is first performed as if the expression or operand were an rvalue. Otherwise, or if the overload resolution fails, overload resolution is performed again, considering the expression or operand as an lvalue.

in a \keyword{return}\iref{stmt.return} or
\keyword{co_return}\iref{stmt.return.coroutine} statement
is a (possibly parenthesized) \grammarterm{id-expression}
that names an implicitly movable entity declared in the body
or \grammarterm{parameter-declaration-clause} of the innermost enclosing
function or \grammarterm{lambda-expression}, or
function or \grammarterm{lambda-expression},
in either case having a non-reference return type, or

\item if the operand of a \grammarterm{throw-expression}\iref{expr.throw}
is a (possibly parenthesized) \grammarterm{id-expression}
Expand Down