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.

### 3790. P1467 accidentally changed `nexttoward`'s signature

Section: 28.7.1 [cmath.syn] Status: New Submitter: David Olsen Opened: 2022-09-30 Last modified: 2022-11-12

Priority: 1

View other active issues in [cmath.syn].

View all other issues in [cmath.syn].

View all issues with New status.

Discussion:

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.

[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 28.7.1 [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);
>    >     […]

[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.

Previous resolution [SUPERSEDED]:

> This wording is relative to N4917.

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

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

[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.

Proposed resolution:

This wording is relative to N4917.

1. Modify 28.7.1 [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 28.7.1 [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.