P1467R9 Extended Floating-Point Types#3583
Conversation
There was a problem hiding this comment.
In WG21-P1467R9, 9.3.6 adds a requirement that specializations of std::complex are trivially-copyable; should we have test coverage?
|
@strega-nil-ms @CaseyCarter I've pushed test coverage as requested, after finding the best place to add it. |
|
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
|
I think at least std::float32_t and std::float64_t should be implemented atm, both could be aliases to float and double respectively, since these two types based on the MSVC's implementation, accomplish the requirements of std::float32_t and std::float64_t |
This is not allowed by the standard. I want to add |
|
What is the actual point of adding this header if it does not contain std::float32_t or std::float64_t atleast... |
We don't design the Standard Library, we just implement it. The working draft for the C++23 Standard says this header exists - it's not optional - so here it is. |
Fixes #2956.
<stdfloat>contains a couple of comments explaining why it's almost, but not completely, empty.<__msvc_all_public_headers.hpp>.<yvals_core.h>contains a clarifying comment, so that readers will understand what we're claiming to support.<stdfloat>itself providesnamespace std, but the comment in the header ensures that we won't remove this during maintenance. It doesn't seem to be worth spending further test throughput to verify one of the world's emptiest headers.