Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

[stmt.return,class.{ctor,dtor}] Clarify no return operand #4737

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

Merged
merged 1 commit into from
Jan 14, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
[stmt.return,class.{ctor,dtor}] Clarify no return operand
Highlight that constructors and destructors do not have a
return type and thus a return statement within a constructor
or destructor cannot have an operand.
  • Loading branch information
jensmaurer committed Jan 14, 2022
commit 516a4b38146760ba8e88c482bbb522f6ddb8f73b
16 changes: 11 additions & 5 deletions 16 source/classes.tex
Original file line number Diff line number Diff line change
Expand Up @@ -1208,12 +1208,13 @@
most derived object\iref{intro.object} ends.

\pnum
\indextext{restriction!constructor}%
A
\tcode{return}
statement in the body of a constructor shall not specify a return value.
\indextext{constructor!address of}%
The address of a constructor shall not be taken.
\indextext{restriction!constructor}%
\begin{note}
A \tcode{return} statement in the body of a constructor
cannot specify a return value\iref{stmt.return}.
\end{note}

\pnum
A constructor shall not be a coroutine.
Expand Down Expand Up @@ -2071,8 +2072,13 @@
the selected destructor may be deleted\iref{dcl.fct.def.delete}.

\pnum
\indextext{restriction!destructor}%
\indextext{destructor!address of}%
The address of a destructor shall not be taken.
\indextext{restriction!destructor}%
\begin{note}
A \tcode{return} statement in the body of a destructor
cannot specify a return value\iref{stmt.return}.
\end{note}
\indextext{\idxcode{const}!destructor and}%
\indextext{\idxcode{volatile}!destructor and}%
A destructor can be invoked for a
Expand Down
7 changes: 5 additions & 2 deletions 7 source/statements.tex
Original file line number Diff line number Diff line change
Expand Up @@ -811,15 +811,18 @@
\indextext{\idxcode{return}!constructor and}%
\indextext{\idxcode{return}!constructor and}%
A \tcode{return} statement with an operand of type \keyword{void} shall be used only
in a function whose return type is \cv{}~\keyword{void}.
in a function that has a \cv{}~\keyword{void} return type.
A \tcode{return} statement with any other operand shall be used only
in a function whose return type is not \cv{}~\keyword{void};
in a function that has a return type other than \cv{}~\keyword{void};
\indextext{conversion!return type}%
the \tcode{return} statement initializes the
returned reference or prvalue result object
of the (explicit or implicit) function call
by copy-initialization\iref{dcl.init} from the operand.
\begin{note}
A constructor or destructor does not have a return type.
Copy link
Contributor

@xmh0511 xmh0511 Aug 7, 2021

Choose a reason for hiding this comment

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

If we claim that a constructor of a class does not have a return type, consider [dcl.init.general] p15

if the function is a constructor, the call is a prvalue of the cv-unqualified version of the destination type whose result object is initialized by the constructor.

[expr.call] p14

A function call is an lvalue if the result type is an lvalue reference type or an rvalue reference to function type, an xvalue if the result type is an rvalue reference to object type, and a prvalue otherwise.

These rules will be in conflict. How could the call of a constructor be a prvalue of the cv-unqualified version of the destination type?

Similarly, if a destructor does not have a return type, how does the following rule work?

If the postfix-expression names a destructor or pseudo-destructor ([expr.prim.id.dtor]), the type of the function call expression is void;

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not seeing the quoted text in [dcl.init.general] p15.

A constructor invocation is not a syntactic function call as described in [expr.call] (it's an explicit type conversion instead), thus any statements about the type of the function call expression don't apply.

We can explicitly call a destructor in a function call expression, and the rule you're quoting overrides the general rule that the type of a function call expression is the return type of the called function.

I'm not seeing any conflicts.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not seeing the quoted text in [dcl.init.general] p15.

It is moved to dcl.init#general-16.6.3 in the current draft

if the function is a constructor, the call is a prvalue of the cv-unqualified version of the destination type whose result object is initialized by the constructor. The call is used to direct-initialize, according to the rules above, the object that is the destination of the copy-initialization.

Copy link
Contributor

Choose a reason for hiding this comment

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

@jensmaurer Final thoughts?

Copy link
Member Author

Choose a reason for hiding this comment

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

Constructors / destructors don't have a return type in the "function declaration" sense, and that absence makes "return something" syntactically ill-formed. I think the quoted stuff doesn't change that; it just means that a constructor call (in the context of copy-initialization, not in general) has (is considered to have) a certain type and value category. That has no bearing on the syntactic constraints on constructor declarations.

I thinks this should go in.

\end{note}
\begin{note}
A \tcode{return} statement can involve
an invocation of a constructor to perform a copy or move of the operand
if it is not a prvalue or if its type differs from the return type of the function.
Expand Down
Morty Proxy This is a proxified and sanitized view of the page, visit original site.