Title
P1467 accidentally changed nexttoward's signature
Status
new
Section
[cmath.syn]
Submitter
David Olsen

Created on 2022-09-30.00:00:00 last changed 3 weeks ago

Messages

Date: 2022-11-12.06:40:36

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.
Date: 2022-11-15.00:00:00

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

Date: 2022-10-15.00:00:00

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

This wording is relative to N4917.

  1. Modify [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);
    […]
    
Date: 2022-10-15.00:00:00

[ 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);
    […]
    
Date: 2022-09-30.00:00:00

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.

History
Date User Action Args
2022-11-12 03:17:02adminsetmessages: + msg13040
2022-10-15 10:57:29adminsetmessages: + msg12870
2022-10-10 10:23:00adminsetmessages: + msg12847
2022-10-01 15:45:17adminsetmessages: + msg12837
2022-09-30 00:00:00admincreate