[stmt.return] Fix the operand's conversions description #4107

languagelawyer · 2020-08-01T21:54:12Z

This is a follow up on #3124/#3587 @sdkrystian @jensmaurer .

This is by no means complete, lotsa wording after the changes and till the end of the subclause seems very broken, namely:

The destructor for the returned object
is potentially invoked~(\ref{class.dtor}, \ref{except.ctor}).
\begin{example}
\begin{codeblock}
class A {
  ~A() {}
};
A f() { return A(); }   // error: destructor of \tcode{A} is private (even though it is never invoked)
\end{codeblock}
\end{example}

There is no "returned object" in A f() { return A(); }. The normative part and the Example should be reworded.

\pnum
The copy-initialization of the result of the call is sequenced before the...

We don't have a copy-initialization of the result, so this should also be reworded.

jensmaurer · 2020-08-01T22:30:53Z

Why don't we have copy-initialization for the return value?

languagelawyer · 2020-08-01T22:38:25Z

Why don't we have copy-initialization for the return value?

Because we don't initialize values in C++. If you mean why don't we initialize the result, well, because the result is either a value, which I've already covered, or an object, which is already initialized somewhere, or function, which doesn't need initialization. For example:

int& f(int& ref) { return ref; #1 }

int main()
{
    int i = 0; #2
    f(i);
}

What does the return statement in #1 initialize? The result of its operand, which is i? It has already been initialized in #2.

jensmaurer · 2020-08-01T22:46:37Z

We still call "int& i = x" copy-initialization, I believe. I'm not seeing a material difference to what we do for the "return" case (except for trying rvalues before lvalues in certain cases).

languagelawyer · 2020-08-01T22:57:44Z

Basically what I'm trying to fix is described in this comment. After #3587, [expr.call] says:

The result of a function call is the result of the possibly-converted operand of the return statement...

With [stmt.return] saying:

the return statement initializes the glvalue result or prvalue result object of the (explicit or implicit) function call

we have a sort of circularity, as described in that comment: the return statement initializes the result of its operand from the result of its operand.

With my fix, [stmt.return] only determines the sequence of conversion. [expr.call] relies on it to say what is the result of a function call.

We still call "int& i = x" copy-initialization, I believe. I'm not seeing a material difference to what we do for the "return" case

I believe, more correct would be to say that in C++ we don't initialize objects, but variables and non-static data members. And in int& f(int& ref) { return ref; }, there is none of them. But this is a bit of a stretch.

BTW, you didn't answer what is initialized by the return statement in my code.

jensmaurer · 2020-08-01T23:01:42Z

I think we initialize a return value (in the broadest sense; here, it's a reference) that is then discarded. (If we were returning an object, we'd call the destructor on it when we discard it.)

And we do initialize objects; there's a fresh initialization of the fresh object designated by the variable i for each recursive entry into f:

void f()
{
  int i = 0;
  f();  // pretend we terminate the recursion at some point
}

languagelawyer · 2020-08-01T23:05:13Z

I think we initialize a return value (in the broadest sense; here, it's a reference)

A glvalue is an expression which denotes an object or function. The result of a glvalue is the ~~entity~~ object or function denoted by the expression. If we say «the return statement initializes the glvalue result», we can't initialize a reference, because there is no such kind of glvalue result.

jensmaurer · 2020-08-01T23:17:56Z

The glvalue refers to i (at #2).

languagelawyer · 2020-08-01T23:23:16Z

The glvalue refers to i

I don't understand what do you want to say here. The glvalue result (of f(i) or ref in the return statement) is i and the return statement initializes it again (I mean, after this object has been initialized in int i = 0;)?

jensmaurer · 2020-08-01T23:25:37Z

No. The call f(i) results in a glvalue (which is discarded) that refers to the object designated by "i".

languagelawyer · 2020-08-01T23:31:01Z

The call f(i) results in a glvalue (which is discarded) that refers to the object designated by "i".

Ok, IIUC we agree that the result of f(i) is the object designated by i. Now, [stmt.return] says: «the return statement initializes the glvalue result ... of the (explicit or implicit) function call by copy-initialization from the operand». So, the object designated by i is copy-initialized from the operand ref, which denotes the same object, the object designated by i. Can we initialize an object twice? 🤔

jensmaurer · 2020-08-01T23:58:54Z

The result of f(i) is a glvalue that refers to i.
The copy-initialization is of an anonymous reference that turns into the glvalue result of the function call expression. We definitely don't initialize i upon return, and I'm not seeing the words as saying such. (I do agree there is room for improvement, but avoiding the term "copy-initialization" here might not be the best way forward.)

languagelawyer · 2020-08-02T00:22:01Z

The copy-initialization is of an anonymous reference

As I've already said, there can't be such glvalue result as "a[n anonymous] reference".
Where does "an anonymous reference" come from, after all? Which wording? The (IMO, abominable) wording «A return statement ... initializes the object or reference to be returned from the function» was removed from [stmt.return] by P0135R1. I think it is better not to resurrect that dead wording.

that turns into the glvalue result of the function call expression

[expr.call] says: «The result of a function call is the result of the possibly-converted operand of the return statement». There is no need in anonymous references.

avoiding the term "copy-initialization" here might not be the best way forward

I'm not avoiding it:

... if the parenthesized operand was used to copy-initialize a hypothetical variable ...

jensmaurer · 2020-08-02T07:43:51Z

You're removing "return statement" from the list of copy-initialization contexts, it seems.

languagelawyer · 2020-08-02T07:50:50Z

Because it doesn't really perform a copy-initialization. It uses imaginary variable copy-initialization just to determine the sequence of conversions to be applied to the operand. Maybe I should reword [stmt.return] to say that it initializes an imaginary variable by the initializer of the form = ( the operand ), then it will be 100% clear that "function return" doesn't need to be listed, because the initialization of such a form is already covered?

jensmaurer · 2020-08-02T08:45:46Z

Saying that a hypothetical variable is copy-initialized sounds reasonable; I'm not sure we need to spell out the explicit syntax. However, if we say that, "return" should certainly stay in the list for copy-initialization in [dcl.init].

Before we dig any deeper, I'm increasingly getting the impression we're leaving "editorial issue" grounds here.

languagelawyer · 2020-08-02T09:18:50Z

Before we dig any deeper, I'm increasingly getting the impression we're leaving "editorial issue" grounds here.

I understand, the change of the «the \tcode{return} statement initializes the ... prvalue result object» wording could raise doubts if programs have the same meaning under the new wording.

languagelawyer · 2020-08-02T10:11:24Z

I'm not sure we need to spell out the explicit syntax.

BTW, do we need to parenthesize the operand?

languagelawyer · 2020-08-02T17:27:03Z

BTW, do we need to parenthesize the operand?

We can't even parenthesize it, because if the operand is braced-init-list, the parenthesized operand can't be used as a variable initializer :(

languagelawyer · 2020-08-03T08:39:31Z

So, after thinking for a little bit more: both [stmt.return] and [expr.call] need fix. More complex than which I've proposed here.
For functions with a non-reference return type, the current wording in [stmt.return]:

the return statement initializes the ... prvalue result object of the (explicit or implicit) function call by copy-initialization from the operand.

looks OK, but the current [expr.call] wording:

The result of a function call is the result of the possibly-converted operand of the return statement

looks defective. The operand can be a braced-init-list which is not a (prvalue) expression, so it doesn't have a result.

Functions with reference return types will have to be handled differently, probably in a way similar to how it was proposed at the end of #3124 (comment)

xmh0511 · 2020-09-02T06:00:59Z

So, after thinking for a little bit more: both [stmt.return] and [expr.call] need fix. More complex than which I've proposed here.
For functions with a non-reference return type, the current wording in [stmt.return]:

the return statement initializes the ... prvalue result object of the (explicit or implicit) function call by copy-initialization from the operand.

looks OK, but the current [expr.call] wording:

The result of a function call is the result of the possibly-converted operand of the return statement

looks defective. The operand can be a braced-init-list which is not a (prvalue) expression, so it doesn't have a result.

Functions with reference return types will have to be handled differently, probably in a way similar to how it was proposed at the end of #3124 (comment)

Agree! I think the wording "glvalue result" is so unclear in [stmt.return] p2 sentence 4, what actually the wording intents to refer to?

Maybe the proposal in that link should be changed to :

If a function call is a prvalue, the prvalue result object is copy-initialized with the possibly-converted operand of the return statement which transferred control out of the called function. Otherwise, it's a gvalue with the type to which the return type referenced , such a glvalue refers to the possibly-converted operand of the return statement which transferred control out of the called function.

I think It will be more better. My reason is , It will also cover this case:

int& f(int& ref) { return ref; #1 }

int main()
{
    int i = 0; #2
    int v = f(i); // ok , `f(i)` is a glvalue of type int, which refers to `i`. and v is copy-initialized by the result from after applying l-to-r conversion to `i`.   
}

That is said, the entity which will be initialized by f(i) is not necessary of reference type.

jwakely · 2020-09-02T08:33:58Z

The suggested changes do not seem like an improvement to me. They do not make anything more clear. Quite the opposite.

[stmt.return] defines what happens. [expr.call] is just referring to that definition not redefining it or contradicting it. Arguably the language in [expr.call] is a bit informal, but I don't see any circularity.

I read the "is the result of the possibly-converted operand" in [expr.call] to mean the same thing as [stmt.return], namely that the result is copy-initialized from the operand, which might require a conversion.

xmh0511 · 2020-09-02T08:53:37Z

The suggested changes do not seem like an improvement to me. They do not make anything more clear. Quite the opposite.

[stmt.return] defines what happens. [expr.call] is just referring to that definition not redefining it or contradicting it. Arguably the language in [expr.call] is a bit informal, but I don't see any circularity.

I read the "is the result of the possibly-converted operand" in [expr.call] to mean the same thing as [stmt.return], namely that the result is copy-initialized from the operand, which might require a conversion.

However, I think the wording "glvalue result" in [stmt.return] is unclear. where is the definition for such a wording in the standard document? So for example,

int& func(int& ref){
  return ref;
}
int main(){
  int a = 0;
  int& v = func(a);
}

The function call expression, namely func(a) is used to initialize a reference v, However what's the "glvalue result" in this declaration? Is the following rule relevant to this wording?

The result of a glvalue is the entity denoted by the expression.

Consider the below rule which is said in [stmt.return] section

the return statement initializes the glvalue result or prvalue result object of the (explicit or implicit) function call by copy-initialization from the operand.

IIUC, for my example, presumably, what the actually intent of this sentence is saying that, the reference v is copy-initialized by operand of return statement as if it is initialized by int& v = ref;

But I have to say that in the declaration int& v = func(a); where v is a declarator-id, how could it be an expression? much less to say it's a glvalue.

jwakely · 2020-09-02T11:31:32Z

The result of the function is just the expression func(a) not the statement that also declares v.

languagelawyer · 2020-09-02T11:48:10Z

The suggested changes do not seem like an improvement to me. They do not make anything more clear. Quite the opposite.

The aim to make "anything more clear" of the suggested changes is not. The aim is to correctly formalize the guaranteed copy elision. Formalized wording often looks less "clear" than colloquial description. Ofc everyone "knows" that

T f() { return e; }
T v = f();

is "equivalent" to T v = e; (except that this is not 100% syntactic substitution, because e can be a comma-separated list of expressions, which is not allowed in the initializer grammar), without even looking into [expr.call] or [stmt.return].

I read the "is the result of the possibly-converted operand" in [expr.call] to mean the same thing as [stmt.return], namely that the result is copy-initialized from the operand, which might require a conversion.

As it was discussed above, in some cases this means that the [object, denoted by the] operand is copy-initialized from itself, when it has already been initialized somewhere else. This is nonsense.
Also, as I've already mentioned, the operand can be an initializer-list, like return {};, which is not "converted" and which is not an expression, so it is unclear what is the result of this operand.

I think the wording "glvalue result" in [stmt.return] is unclear. where is the definition for such a wording in the standard document?

https://timsong-cpp.github.io/cppwp/n4659/basic.lval#def:result,glvalue

xmh0511 · 2020-09-02T12:20:48Z

The suggested changes do not seem like an improvement to me. They do not make anything more clear. Quite the opposite.

Aim to make "anything more clear" of the suggested changes is not. The aim is to correctly formalize the guaranteed copy elision. Formalized wording often looks less "clear" than colloquial description. Ofc everyone "knows" that
T f() { return e; }
T v = f();
is "equivalent" to T v = e; (except that this is not 100% syntactic substitution, because e can be a comma-separated list of expressions, which is not allowed in the initializer grammar), without even looking into [expr.call] or [stmt.return].

I read the "is the result of the possibly-converted operand" in [expr.call] to mean the same thing as [stmt.return], namely that the result is copy-initialized from the operand, which might require a conversion.

As it was discussed above, in some cases this means that the [object, denoted by the] operand is copy-initialized from itself, when it has already been initialized somewhere else. This is nonsense.
Also, as I've already mentioned, the operand can be an initializer-list, like return {};, which is not "converted" and which is not an expression, so it is unclear what is the result of this operand.

I think the wording "glvalue result" in [stmt.return] is unclear. where is the definition for such a wording in the standard document?

https://timsong-cpp.github.io/cppwp/n4659/basic.lval#def:result,glvalue

Yes, that's the relevant quote. However, consider such a statement int& v = func(a);, which is the "glvalue result" in this declaration? Is it the expression func(a)?

languagelawyer · 2020-09-05T15:17:00Z

The result of the function is just the expression func(a)

The result of a glvalue can be an object or function. Not an expression.

However, consider such a statement int& v = func(a);, which is the "glvalue result" in this declaration?

The result is [the object denoted by] a.

xmh0511 · 2020-09-05T16:42:46Z

The result of the function is just the expression func(a)

The result of a glvalue can be an object or function. Not an expression.

However, consider such a statement int& v = func(a);, which is the "glvalue result" in this declaration?

The result is [the object denoted by] a.

So, that is said , the "glvalue result" which is a is copy-initialized from the operand of the return statement, that is, it initializes which is itself. It's so weird.

jensmaurer · 2020-12-04T17:58:00Z

Editorial meeting: "copy-initialization" is not good, talk about "full-expression is sequenced before".
Also, "returned object" is not good.

languagelawyer · 2020-12-04T18:00:15Z

Also, "returned object" is not good.

#4112

tkoeppe · 2020-12-14T16:51:11Z

@jensmaurer: To be clear, the present patch does not (yet) reflect the editorial consensus, right?

jensmaurer · 2020-12-14T16:56:40Z

@jensmaurer: To be clear, the present patch does not (yet) reflect the editorial consensus, right?

Right.

xmh0511 · 2021-05-07T09:34:00Z

It appears to me that, the following wording would more consistent with the behavior of the major implementations.

the return statement initializes the prvalue result object of the (explicit or implicit) function call by copy-initialization from the operand.

Otherwise, if the function call is a glvalue, the return statement is equivalent to the following hypothetical declaration

T t = e; where e is the original operand of the return statement and T is the return type of the function.

The variable t is used as the result of the function call.

After this rewording, stmt.return#5 can still be consistent in either case. The t is so-called anonymous reference mentioned by @jensmaurer. Please take a look at this proposal @jensmaurer @languagelawyer

languagelawyer · 2021-05-07T12:49:25Z

T t = e; where e is the original operand of the return statement

return allows comma-separated operand (e1, e2, ..., en), but initializer grammar doesn't.

The t is so-called anonymous reference

I think I don't want to see anonymous references back.

xmh0511 · 2021-05-07T13:04:26Z

T t = e; where e is the original operand of the return statement

return allows comma-separated operand (e1, e2, ..., en), but initializer grammar doesn't.

Why would be that? For declaration T t = (e1,e2,e3); where = (e1,e2,e3,...,en) is the initializer, which obeys the grammar initializer = initializer-clause . (e1,e2,e3,...,en) is the original operand of the return statement.

The t is so-called anonymous reference

I think I don't want to see anonymous references back.

I just say that t is the anonymous reference that jensmaurer said, it's not normative wording. I mean such wording can be used as the source for the informal wording anonymous reference

languagelawyer · 2021-05-07T13:11:31Z

Why would be that? ... (e1,e2,e3,...,en) is the original operand of the return statement.

I meant return e1, e2, e3;, not return (e1, e2, e3);.

And the main difficulty here is how to describe function call prvalue result in case return's operand is a braced list. «The result of a function call is the result of the possibly-converted operand of the return statement» can't work since braced list is not an expression and thus doesn't have result.

xmh0511 · 2021-05-07T13:22:06Z

Why would be that? ... (e1,e2,e3,...,en) is the original operand of the return statement.

I meant return e1, e2, e3;, not return (e1, e2, e3);.

And the main difficulty here is how to describe function call prvalue result in case return's operand is a braced list. «The result of a function call is the result of the possibly-converted operand of the return statement» can't work since braced list is not an expression and thus doesn't have result.

I think it is not necessary to change the wording about copy-initialization for prvalue result object, it works well, it remains

the return statement initializes the prvalue result object of the (explicit or implicit) function call by copy-initialization from the operand.

It's sufficient well. no matter what the operand is(expression or braced-init-list). I think that we just pay attention to the wording for the case of the glvalue result.

I think we just amend the wording that I said by adding the special case return comma-expression.

xmh0511 · 2021-05-07T13:38:17Z

@languagelawyer Since you mention the special case return comma-expression, I also think that the same issue also exists in dcl.type.auto.deduct#2.1. fun(e1,e2) has the different syntactic meaning with fun((e1,e2)), which should be considered defect.

languagelawyer · 2021-05-07T13:40:30Z

@xmh0511 #4315

xmh0511 · 2021-05-07T13:48:16Z

@xmh0511 #4315

Well. It's good wording. I think we can use the same manner for the special case return comma-expression in the wording for describing the return statement for the glvalue result case. So, change the wording to

Otherwise, if the function call is a glvalue, the return statement is equivalent to the following hypothetical declaration

T t = e;
if the operand is an expression X that is not an assignment-expression(i.e, comma expression), e is (X), otherwise e is X. T is the return type of the function call.

The variable t is used as the result of the function call.

tkoeppe · 2022-08-22T21:04:52Z

Please reopen if you would like to continue with this.

languagelawyer marked this pull request as draft August 1, 2020 21:54

languagelawyer force-pushed the stmt.return branch from 6414ae2 to d5234f5 Compare August 1, 2020 22:05

languagelawyer changed the title ~~[stmt.return] Fix operand conversions description~~ [stmt.return] Fix the operand's conversions description Aug 1, 2020

languagelawyer force-pushed the stmt.return branch 2 times, most recently from a5d8063 to 4787329 Compare August 1, 2020 22:30

[stmt.return] Fix the operand's conversions description

eb9254a

languagelawyer force-pushed the stmt.return branch from 4787329 to eb9254a Compare August 1, 2020 22:32

jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Aug 1, 2020

jensmaurer force-pushed the master branch from 1ed19b9 to 2edf19f Compare September 30, 2020 19:39

jensmaurer removed the decision-required A decision of the editorial group (or the Project Editor) is required. label Dec 4, 2020

xmh0511 mentioned this pull request Jun 28, 2021

Reword the wording for glvalue result of a function call CWG2495 #4724

Closed

jensmaurer added the needs rebase The pull request needs a git rebase to resolve merge conflicts. label Oct 25, 2021

xmh0511 mentioned this pull request Apr 27, 2022

[expr.call] The result type of a function call and the value category relying on it #5415

Closed

tkoeppe closed this Aug 22, 2022

xmh0511 mentioned this pull request Nov 29, 2022

Clarify the ambiguous meaning arising from [expr.call] and [stmt.return] cplusplus/CWG#186

Open

[stmt.return] Fix the operand's conversions description #4107

[stmt.return] Fix the operand's conversions description #4107

Conversation

languagelawyer commented Aug 1, 2020 • edited

jensmaurer commented Aug 1, 2020

languagelawyer commented Aug 1, 2020 • edited

jensmaurer commented Aug 1, 2020

languagelawyer commented Aug 1, 2020

jensmaurer commented Aug 1, 2020 • edited

languagelawyer commented Aug 1, 2020 • edited

jensmaurer commented Aug 1, 2020

languagelawyer commented Aug 1, 2020

jensmaurer commented Aug 1, 2020

languagelawyer commented Aug 1, 2020

jensmaurer commented Aug 1, 2020

languagelawyer commented Aug 2, 2020 • edited

jensmaurer commented Aug 2, 2020

languagelawyer commented Aug 2, 2020 • edited

jensmaurer commented Aug 2, 2020

languagelawyer commented Aug 2, 2020

languagelawyer commented Aug 2, 2020

languagelawyer commented Aug 2, 2020

languagelawyer commented Aug 3, 2020

xmh0511 commented Sep 2, 2020 • edited

jwakely commented Sep 2, 2020

xmh0511 commented Sep 2, 2020 • edited

jwakely commented Sep 2, 2020

languagelawyer commented Sep 2, 2020 • edited

xmh0511 commented Sep 2, 2020 • edited

languagelawyer commented Sep 5, 2020

xmh0511 commented Sep 5, 2020 • edited

jensmaurer commented Dec 4, 2020

languagelawyer commented Dec 4, 2020

tkoeppe commented Dec 14, 2020

jensmaurer commented Dec 14, 2020

xmh0511 commented May 7, 2021 • edited

languagelawyer commented May 7, 2021 • edited

xmh0511 commented May 7, 2021 • edited

languagelawyer commented May 7, 2021

xmh0511 commented May 7, 2021 • edited

xmh0511 commented May 7, 2021 • edited

languagelawyer commented May 7, 2021

xmh0511 commented May 7, 2021

tkoeppe commented Aug 22, 2022

languagelawyer commented Aug 1, 2020 •

edited

languagelawyer commented Aug 1, 2020 •

edited

jensmaurer commented Aug 1, 2020 •

edited

languagelawyer commented Aug 1, 2020 •

edited

languagelawyer commented Aug 2, 2020 •

edited

languagelawyer commented Aug 2, 2020 •

edited

xmh0511 commented Sep 2, 2020 •

edited

xmh0511 commented Sep 2, 2020 •

edited

languagelawyer commented Sep 2, 2020 •

edited

xmh0511 commented Sep 2, 2020 •

edited

xmh0511 commented Sep 5, 2020 •

edited

xmh0511 commented May 7, 2021 •

edited

languagelawyer commented May 7, 2021 •

edited

xmh0511 commented May 7, 2021 •

edited

xmh0511 commented May 7, 2021 •

edited

xmh0511 commented May 7, 2021 •

edited