CWG2723 [basic.fundamental] Ranges of representable values are underspecified for floating-point types

[frederick-vs-ja]

Full name of submitter (unless configured in github; will be published with the issue): Jiang An

Reference (section label): [basic.fundamental]

Link to reflector thread (if any):

Issue description:
Currently the range of representable values of a given floating-point type is underspecified in [basic.fundamental], but the range is already referred in [lex.fcon] p3 and the library wording (e.g. in [charconv.from.chars] p1 and [facet.num.get.virtuals] p3).

The range is well-specified in C, perhaps C++ should adopt the C wording.

Suggested resolution:

Insert a new paragraph immediately after [basic.fundamental] p12 (originally WG14 N3096 5.2.4.2.2 p13):

X. The minimum range of representable values for a floating-point type is the most negative finite floating-point number representable in that type through the most positive finite floating-point number representable in that type. In addition, if negative infinity is representable in a type, the range of that type is extended to all negative real numbers; likewise, if positive infinity is representable in a type, the range of that type is extended to all positive real numbers.

Insert a note for ISO 60559 types immediately after the new paragraph (originally WG14 N3096 F.2.1 p1):

[Note X: Since negative and positive infinity are representable in ISO/IEC/IEEE 60559 formats, all real numbers lie within the range of representable values of a floating-point type adhering to ISO/IEC/IEEE 60559. — end note]

[jensmaurer]

CWG2723

@jwakely, heads-up. I think I had an LWG-related discussion about this topic a while back.

[jwakely]

We discussed it in the context of https://cplusplus.github.io/LWG/issue3081

https://isocpp.org/files/papers/P2827R0.html tries to address it, but doesn't consider the "range of representable values" problem.

[jensmaurer]

@jwakely , ok.

Note that the suggested resolution for this core issue will define "range of representable values" as going from -inf to +inf for IEEE floating-point types, which impacts library semantics (probably in a good way), but P2827 in particular might need adjustments.

If this is undesirable, maybe this needs to be factored into a paper so that it can more freely move between LWG and CWG.