This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

4621. Floating-point std::midpoint should not be freestanding

Section: 26.10.16 [numeric.ops.midpoint] Status: New Submitter: Jan Schultke Opened: 2026-09-11 Last modified: 2026-09-22

Priority: Not Prioritized

View other active issues in [numeric.ops.midpoint].

View all other issues in [numeric.ops.midpoint].

View all issues with New status.

Discussion:

The standard library typically does not provide freestanding floating-point numerics, but floating-point std::midpoint is freestanding, presumably by accident. LWG 4614(i) makes this pre-existing issue readily apparent by making floating-point std::midpoint (freestanding) equivalent to std::lerp(a, b, T(0.5)) (not freestanding).

Proposed resolution:

This wording is relative to N5054 on top of LWG 4614(i).

  1. Modify 26.9 [numeric.ops.overview] as indicated:

    […]
// 26.10.16 [numeric.ops.midpoint], midpoint
template<classintegral T>
  constexpr T midpoint(T a, T b) noexcept;
template<floating_point T>
  constexpr T midpoint(T a, T b) noexcept; // freestanding-deleted
template<class T>
  constexpr T* midpoint(T* a, T* b);
[…]

  2. Modify 26.10.16 [numeric.ops.midpoint] as indicated:

    [Drafting note: The seemingly loss of "No overflow occurs." for floating-point is still implied as part of the specification interms of lerp. For the floating-point part, "no overflow" presumably means that it won't return infinity given finite inputs, and lerp is specified as returning a mathematical value:

    Returns: a + t(b-a).

    The Remarks element constrains it further to be finite, so I would say that 29.7.4 [c.math.lerp] says multiple times that no "overflow" can occur already in the sense of finiteness.

    One might also interpret "no overflow" as not spuriously raising FE_OVERFLOW. Even that interpretation is covered: https://cstd.eisie.net/c23#7.12.1p1 bans all <math.h> function from spuriously raising overflow exceptions, and we recently made that wording apply to everything in <cmath> including std::lerp.] 

    template<classintegral T>
  constexpr T midpoint(T a, T b) noexcept;

    -1- Constraints: T is an arithmetic type other thannot cv bool.

    -2- Effects: If T is a floating-point type, equivalent to return lerp(a, b, T(0.5)); (29.7.4 [c.math.lerp]). Otherwise, returns half
    Returns: Half the sum of a and b; if the sum is odd, the result is rounded towards a.

    -3- Remarks: No overflow occurs. If T is a floating-point type, at most one inexact operation occurs. 

    template<floating_point T>
  constexpr T midpoint(T a, T b) noexcept;

    -?- Effects: Equivalent to: return lerp(a, b, T(0.5)); (29.7.4 [c.math.lerp])

    -?- Remarks: At most one inexact operation occurs.