The result of the function call expression f() is the variable b. That is the same object that is initialized in the return-statement of the function. This is how the guaranteed copy elision mechanism works: the return-statement does directly initialize the object that the function call initializes. (Except for the special case in [class.temporary]p3 that permits a copy -- which does appear to be incorrect, in that it applies only to class types and should apply to all objects. I'm going to file a core issue for that.)

@zygoloid I don't really agree.

The result of the function call expression f() is the variable b

The result of a prvalue is "the value it stores into it's context". b is not a value. The result object would be the object denoted by b.

The operand of the return statement here is the glvalue a. The result of a glvalue is the entity that it denotes; in this case, an object. This does not match with the definition of what the result of a prvalue is (a value).

@zygoloid Addtionally, consider a situation like this:

float a = 0;
int f()
{
  return a;
}

int b = f();

Here, the "result of the operand of the evaluated return statement" is an object of type float. With the existing wording, that would make the result of the function call an object of type float too, even though it is a prvalue of type int, and prvalues are defined to result in a value.

OK, I see what you're saying now. Yes, it would be clearer if we said the result of the function call is the result of the possibly-converted operand of the evaluated return statement, or something like that.

There's another problem here: we can evaluate more than one return statement, in a case like

struct X { ~X() noexcept(false) { throw 0; } };
int f() {
  try {
    X x;
    return 1;
  } catch (int) {
    return 2;
  }
}

I think something like this would resolve the issue:

The result of a function call is the result of the possibly-converted operand of the evaluated return statement in that transferred control out of the called function

The fix seems pretty obvious to me.

@jensmaurer @zygoloid Hm. I still don't believe the wording is quite fixed.

Consider what this means for a lvalue function call in conjunction with [stmt.return] p4, which says the result of the function call is initialized with the operand of the return statement... but we define the operand as being the result of the function call, and we end up saying that the operand initializes itself.