It seems a bit clearer to use return type instead of result type after excluding (pseudo-)destructor calls (although they are not always the same, the difference doesn't matter here).

(Pseudo-)destructor calls are already specified to have type void and thus can't be glvalues.

It seems a bit clearer to use return type instead of result type

Yes, It was my original thought before proposing the suggestion. However, it still does not clarify the result of the function call, as pointed out in this issue, we lack to specify the destination type of the conversion. So, instead of replacing result type with return type for [expr.call] p14, It might be better to directly clarify the result of the function call.

You reminded me that we should have a special rule to specify the result/value category of the function call whose return type is void, since either it has no operand of the return statement or it is a pseudo-destructor.

Change [expr.call] p9 to

A function call where the return type of the function is T has the same value category and result as:

• if T is cv void, a prvalue of T that has no result.
• Otherwise, if the operand of the return statement ([stmt.return]) that transferred control out of the called function (if any) is E, for an invented declaration T t = E;

• If no conversion is required and E is an expression, E.
• Otherwise, the unqualified-id t; t is an lvalue if T is an lvalue reference type or an rvalue reference to function type ([dcl.ref]), an xvalue if T is an rvalue reference to object type, and a prvalue otherwise.
  [note: E may be a braced-init-list. --end note]

I don't think this is correct. For example,

int f()
{
  int x;
  return x;
}

I think this qualifies as "no conversion is required". The operand of the return statement is an lvalue, yet the function call f() obviously yields a prvalue.

Why wouldn't an lvalue-to-rvalue conversion apply to the operand x in that example? As said in [basic.lval] p5

The result of a prvalue is the value that the expression stores into its context; a prvalue that has type cv void has no result.

Since the function call f() is a prvalue, its result should be the value stored in x where the value is fetched by the way specified in [conv.lval] p3.4:

Otherwise, the object indicated by the glvalue is read ([defns.access]), and the value contained in the object is the prvalue result.

I think the proposed suggestion is not good for class type, consider this example

struct B{};
B fun1(B& b){
    return b;
}

We have said that converting an argument of a class type to the same type is an identity conversion, which means no conversion is required. So, I think the proposed suggestion might be simplified to

Otherwise, if the operand of the return statement ([stmt.return]) that transferred control out of the called function (if any) is E, S is (E) if E is an expression that is not an assignment-expression, or E otherwise. For an invented declaration T t = S;, the function call has the same result and value category as the unqualified-id t; t is an lvalue if T is an lvalue reference type or an rvalue reference to function type ([dcl.ref]), an xvalue if T is an rvalue reference to object type, and a prvalue otherwise. The program is ill-formed If the declaration would be ill-formed.

Without considering what the original operand is. I think the declaration modeling a copy-initialization is consistent with [dcl.init.general] p14.

With this suggestion, I think we should remove the last sentence in [stmt.return] p2, or change it to a note

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

Because, when a function call is a prvalue, it is not limited to being used to initialize an object, such as to be an operand of the operations(i.e. computes the value), that is, there is no result object to be initialized. And what is said in this sentence is covered by the suggestions. Also, it could clarify #4107

See also #4847 and #4723.

The wording should be clear that the type and value category of a function call only depend on the return type written in the function declaration. I think it would be helpful to separate that from the determination of the result (i.e. the value that is returned). I'm wondering whether we could simply say that the operand of the evaluated return copy-initializes the result, which works for both lvalues and prvalues, I think, and does the conversions we want.

I'm wondering whether we could simply say that the operand of the evaluated return copy-initializes the result

As I said above, the function call is not necessarily used to initialize something. Consider this snippet

fun() + 1;

There is no stuff to be initialized(especially, no result object), we just need to read the value for computation. So, the current rule for the return statement obviously cannot cover this usage.

Indeed that using "return type" to directly determine the value category of a function call is clearer. Nonetheless, The result of a function call is also needed to be clarified.

I think it would be helpful to separate that from the determination of the result

Yes, I also think so. However, IMO, to determine the result of a call, we should first determine what the value category is(e.g. a glvalue determine the object or function, a prvalue determines the value), since this is a chain then why wouldn't integrate them into a rule.

For the return statement, I just think the evaluated return statement indicates/provides the corresponding initializer for the invented declaration, use the invented variable as the result of the function call is clear wherever we use the function call as an expression in any context(initialization or computation), that is, we don't need to recall the return statement when considering what the result is, reduce the baggage, I think.

The example in #4847 actually wants to say we should consider any conversions required to match the operand of the return statement to the return type as part of the initialization of the invented declaration, in order to avoid the ambiguity when we say certain conversions are not considered when initializing the actual result object.

With the help of the suggestion, it is easy to interpret the example in #4847 and the corresponding referenced rule will be well.

struct B{
  B(int){}
};
struct A{
  operator B(){   
     return 0;
  }
};
A a;
B const& rf = a;  //#1

the function call to A::operator B is a prvalue defined as

 B t = 0;

t is the result of A::operator B(); and it is a prvalue, which means the result object will be initialized by the constructor B::B(int) with the argument 0 wherever the result is used to initialize an object. According to [dcl.init.ref] p5.4.1, the effect at #1 is the same like:

B const& rf(t);

The direct-initialization obeys [dcl.init.ref] p5.3, no user-defined conversion is required in this initialization.

The issue in #4723 might be fixed by:

The copy-initialization of the returned reference or prvalue result object of the call is sequenced before the destruction of temporaries at the end of the full-expression established by the operand of the return statement...

From a certain perspective, I think the returned reference is the invented variable that is of reference type.

result object case: https://godbolt.org/z/orTWM5Gf7

returned reference case: https://godbolt.org/z/3zq3f5hcd

What the result of a function call is may be clarified by cplusplus/CWG#186, and therefore what the type of the result is. Or, we may just need to use the return type in the rule.