Date: Mon, 22 Dec 2025 11:56:26 -0500
*Brian Bi*
On Mon, Dec 22, 2025, 9:32 AM Russell Shaw via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> 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.
>
What it really means is that those conversions are applied only if doing so
produces a prvalue of a type that the operator can accept for that operand.
> > 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.
>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
On Mon, Dec 22, 2025, 9:32 AM Russell Shaw via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> 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.
>
What it really means is that those conversions are applied only if doing so
produces a prvalue of a type that the operator can accept for that operand.
> > 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.
>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
Received on 2025-12-22 16:56:40
