Proposed resolution:

This wording is relative to N4917.

1. Modify [cmath.syn], header <cmath> synopsis, as indicated:

   […]
   constexpr floating-point-type nexttoward(floating-point-type x, floating-point-typelong double y);
   constexpr float nexttowardf(float x, long double y);
   constexpr long double nexttowardl(long double x, long double y);
   […]
   

2. Add following paragraph at the end of [cmath.syn], header <cmath> synopsis:

   -?- An invocation of nexttoward is ill-formed if the argument corresponding to the floating-point-type parameter has extended floating-point type.

[ 2023-02-13 Approved at February 2023 meeting in Issaquah. Status changed: Voting → WP. ]

[ 2023-01-11; Reflector poll ]

Set status to Tentatively Ready after seven votes in favour during reflector poll.

[ 2022-11-12; Tomasz comments and provides improved wording ]

During 2022-10-26 LWG telecon we decided that we want to make the calls of the nexttoward to be ill-formed (equivalent of Mandates) when the first argument is extended floating-point type.

[ 2022-10-04; David Olsen comments and provides improved wording ]

C23 specifies variants of most of the functions in <math.h> for the _FloatN types (which are C23's equivalent of C++23's std::floatN_t types). But it does not specify those variants for nexttoward.

Based on what C23 is doing, I think it would be reasonable to leave nexttoward's signature unchanged from C++20. There would be no requirement to provide overloads for extended floating-point types, only for the standard floating-point types. Instead of explicitly deleting the overloads with extended floating-point types, we can just never declare them in the first place.

[ 2022-10-10; Reflector poll ]

Set priority to 1 after reflector poll. Discussion during prioritization revolved around whether to delete nexttoward for new FP types or just restore the C++20 signatures, which might accept the new types via implicit conversions (and so return a different type, albeit with the same representation and same set of values).

"When the first argument to nexttoward is an extended floating-point type that doesn't have the same representation as a standard floating-point type, such as std::float16_t, std::bfloat16_t, or std::float128_t (on some systems), the call to nexttoward is ambiguous and ill-formed, so the unexpected return type is not an issue. Going through the extra effort of specifying '= delete' for nexttoward overloads that have extended floating-point arguments is a solution for a problem that doesn't really exist."

Previous resolution [SUPERSEDED]:

This wording is relative to N4917.

1. Modify [cmath.syn], header <cmath> synopsis, as indicated:

   […]
   constexpr floating-point-type nexttoward(floating-point-type x, floating-point-typelong double y);
   constexpr float nexttowardf(float x, long double y);
   constexpr long double nexttowardl(long double x, long double y);
   […]
   

P1467 (Extended floating-point types), which was adopted for C++23 at the July plenary, has a typo (which is entirely my fault) that no one noticed during wording review. The changes to the <cmath> synopsis in the paper included changing this:

constexpr float nexttoward(float x, long double y);       // see [library.c]
constexpr double nexttoward(double x, long double y);
constexpr long double nexttoward(long double x, long double y);   // see [library.c]

to this:

constexpr floating-point-type nexttoward(floating-point-type x, floating-point-type y);

That changed the second parameter of nexttoward from always being long double to being floating-point-type, which matches the type of the first parameter.

The change is obviously incorrect. The purpose of the changes to <cmath> was to add overloads of the functions for extended floating-point types, not to change any existing signatures.