Date: Tue, 23 Dec 2025 01:32:07 +1100
Hello M.P,
I understand what you said, but i'm trying to match it to what the std says
(14882:2024).
On 23/12/25 00:52, M.P. wrote:
> There is no standard conversion sequence that can convert `S` to `int`.
From [basic.lval], the first part of a standard conversion sequence:
Para.1
***********************************************
Whenever a glvalue appears as an operand of an operator that expects a prvalue
for that operand, the lvalue-to-rvalue (7.3.2), array-to-pointer (7.3.3), or
function-to-pointer (7.3.4) standard conversions are applied to convert the
expression to a prvalue.
***********************************************
It sounds like the struct object "s" in "1 + s" is a glvalue.
> The conversion using `S::operator int()` is a user-defined conversion,
> and it is applied to `s` as a result of overload resolution selecting
> the built-in candidate `operator+(int, int)` for this expression. So
> the expression (notionally) becomes
>
> 1 + s.operator int()
>
> and only then is it interpreted as a use of the built-in `+` operator
> according to the rules of [expr] (see [over.match.oper] paragraph 11).
>
> Both operands in this expression are already prvalues. In C++23, their
> values are used as-is, and no lvalue-to-rvalue conversion is ever
> applied.
Thankyou for your guidance. It says in [expr.pre]:
***********************************************
However, these built-in operators participate in overload resolution, and as
part of that process user-defined conversions will be considered where necessary
to convert the operands to types appropriate for the built-in operator. If a
built-in operator is selected, such conversions will be applied to the operands
before the operation is considered further according to the rules in 7.6; see
12.2.2.3, 12.5.
***********************************************
This agrees with what you said, but Para.1 above is very misleading because it
lacks emphasis in the right place to stand out that it only applies after user
conversions are applied.
> In the current draft for C++26, [basic.lval] paragraph 7
> introduces temporary objects to hold the values of the operands. This
> does mean that the resulting xvalues must undergo lvalue-to-rvalue
> conversion to become prvalues again ([basic.lval] paragraph 6), but
> this conversion is applied to the `int` xvalue materialized from
> `s.operator int()`, not the `s` expression itself.
I understand what you said, but i'm trying to match it to what the std says
(14882:2024).
On 23/12/25 00:52, M.P. wrote:
> There is no standard conversion sequence that can convert `S` to `int`.
From [basic.lval], the first part of a standard conversion sequence:
Para.1
***********************************************
Whenever a glvalue appears as an operand of an operator that expects a prvalue
for that operand, the lvalue-to-rvalue (7.3.2), array-to-pointer (7.3.3), or
function-to-pointer (7.3.4) standard conversions are applied to convert the
expression to a prvalue.
***********************************************
It sounds like the struct object "s" in "1 + s" is a glvalue.
> The conversion using `S::operator int()` is a user-defined conversion,
> and it is applied to `s` as a result of overload resolution selecting
> the built-in candidate `operator+(int, int)` for this expression. So
> the expression (notionally) becomes
>
> 1 + s.operator int()
>
> and only then is it interpreted as a use of the built-in `+` operator
> according to the rules of [expr] (see [over.match.oper] paragraph 11).
>
> Both operands in this expression are already prvalues. In C++23, their
> values are used as-is, and no lvalue-to-rvalue conversion is ever
> applied.
Thankyou for your guidance. It says in [expr.pre]:
***********************************************
However, these built-in operators participate in overload resolution, and as
part of that process user-defined conversions will be considered where necessary
to convert the operands to types appropriate for the built-in operator. If a
built-in operator is selected, such conversions will be applied to the operands
before the operation is considered further according to the rules in 7.6; see
12.2.2.3, 12.5.
***********************************************
This agrees with what you said, but Para.1 above is very misleading because it
lacks emphasis in the right place to stand out that it only applies after user
conversions are applied.
> In the current draft for C++26, [basic.lval] paragraph 7
> introduces temporary objects to hold the values of the operands. This
> does mean that the resulting xvalues must undergo lvalue-to-rvalue
> conversion to become prvalues again ([basic.lval] paragraph 6), but
> this conversion is applied to the `int` xvalue materialized from
> `s.operator int()`, not the `s` expression itself.
Received on 2025-12-22 14:32:14
