P1467R9 Extended Floating-Point Types

[CaseyCarter]

It looks like we need to add a header <stdfloat> that declares the std namespace, even if we choose to support no extended floating-point types.

Internal VS-PR-420058 has taught the IDE about this new extensionless header - thanks, me!

Resolved at the February 2023 meeting:
LWG-3790 WG21-P1467R9 accidentally changed nexttoward's signature

[AlexGuteniev]

The header will not be empty.
We should define std::float32_t to float and std::float64_t to double

[frederick-vs-ja]

AFAIK

• MSVC supports no extended floating-point types.
• Clang has _Float16 and __bf16. However, currently no operation on __bf16 is supported, so perhaps __bf16 is not qualified as an extended floating-type at this moment.
• (According to the paper) EDG seemly supports five extended floating-point types mentioned in the paper.

We should decide whether to provide library support specific to Clang and EDG.

We should define std::float32_t to float and std::float64_t to double

@AlexGuteniev I don't think we should do so. P1467R9 requires std::float32_t etc. to be extended floating-point types, and thus distinct from standard floating-point types, even if std::float32_t generally has the same format as float when supported.

[AlexGuteniev]

Understood

[strega-nil-ms]

Until MSVC decides to support _Float16, I would prefer not to add support to the standard library for it.

[simmse]

The header will not be empty. We should define std::float32_t to float and std::float64_t to double

That might be true for all time. However, what about std::float128_t? How soon will all of the supporting templates have std::float128_t?

[CaseyCarter]

The header will not be empty. We should define std::float32_t to float and std::float64_t to double

That would not be conforming. float32_t and float64_t must be extended floating point types, and both float and double are standard floating point types. The extended floating point types and standard floating point types are mutually exclusive sets. If our compilers choose to support extended floating point types with these properties then the library will support them as well, but we can't simply alias them to float and double.

EDIT: frederick-vs-ja already made this point in #2956 (comment).

[simmse]

The header will not be empty. We should define std::float32_t to float and std::float64_t to double

That would not be conforming. float32_t and float64_t must be extended floating point types, and both float and double are standard floating point types. The extended floating point types and standard floating point types are mutually exclusive sets. If our compilers choose to support extended floating point types with these properties then the library will support them as well, but we can't simply alias them to float and double.

Perhaps I should rephrase the question. How soon will std::float128_t be supported? If that means the compiler team has to join this conversation, that would be welcomed. By the way, the C23 standard also has 128 bits precision floating point as a new type. See these for more on the C23 floating point additions:

https://en.cppreference.com/w/c/23
https://open-std.org/JTC1/SC22/WG14/www/docs/n2601.pdf

[StephanTLavavej]

I haven't checked with the compiler team, but I suspect that they have no plans to support extended floating-point types, as they are optional in both C and C++, and they would need to see significant customer demand before starting such optional work.

[CaseyCarter]

I've corrected the OP: <stdfloat> can't conformingly be empty, it needs namespace std {}.

[StephanTLavavej]

I'll take this one - since I have to add non-GitHub changes for #3337 <print> , I may as well do <stdfloat> at the same time.