P1467 Extended floating-point types and standard names #227
P1467R1 Extended Floating Point Types: Design Review
Champion: Michał Dominiak
Minute Taker: Jayesh Badwaik
Start Overview: 07-16 10:42
Start Review: 11:02
Make sure outputting extended floating point types with iostreams works.
Is a type trait needed for determining floating-point conversion rank? Do we need any new type traits for floating point types in this brave new world?
P1468R1 Fixed-Layout Floating Point Type Aliases: Design Review
Champion: Michał Dominiak
Minute Taker: Jayesh ?
Start Overview: 07-16 11:38
Start Review: 11:42
Start Polling: 11:48
POLL: Fixed-type floating point types are allowed to alias
This has strong consensus.
POLL: Have the fixed-layout floating point types only be declared if they are available, and have feature test macros for each type.
NO OBJECTION TO UNANIMOUS CONSENT.
POLL: Forward P1467R0 (with the addition of support for extended floating point types in
A: Want to see more implementation experience.
CONSENSUS: Forward P1467R0 (with the addition of support for extended floating point types in
EWGI in Cologne (seen with #228):
The extended floating-point types should be allowed to alias float/double/long double.
Note one of the above polls reverse a LEWGI poll.
Send to EWG + LEWG.
This was at the Oct 6, 2021 special SG22 session.
POLL: Should the usual arithmetic conversions in C++ follow the rules in C?
Consensus. Weak on the WG21 side.
POLL: Should the C implicit conversion rules change to follow the rules as proposed for C++?
POLL: Should the _Float* C names be available (through some means) in C++ and be used as the types behind the std::float* aliases?
SA vote rationale: My reasons against were that similar but slightly incompatible types is not good for the same names. My recommendation to Microsoft would be against. For the French national body, I can bring the issue to them.
Very weak consensus.
POLL: Use the std::floatN as opposed to std::floatN_t for aliases?
SA vote rationale: Similar reasoning for the previous poll. Should there be an alias at all?
Removing from the SG22 plate.
Discussed at the EWG Teleon on October 21, 2021
EWG approves the direction on overload resolution as presented in D1467R6.
2021-11-15 Library Evolution Telecon
P1467R6: Extended floating-point types and standard names
Chair: Fabio Fracassi
Champion: David Olsen
Minute Taker: Mark Hoemmen & Bronek Kozicki
Does this proposal have:
Finer grained feature test macros
Topics to Poll:
POLL: Should we require the C names (_Float16, etc...) to be available
POLL: The literal suffixes should be a core language feature.
POLL: Assuming we resolve feature test macros in a separate mailing list review we forward this paper with the literal suffixes removed to EWG to be confirmed by electronic polling (P3 new features).
We went over this paper in detail. The complexity of this paper comes form the interactions and compatibility requirements both form the existing types as well as incoming C23 types with the same purpose. The proposed solution put the new types in the
We decided that the literals should be implemented in the core language instead of the library (subject to EWG approval).
LEWG electronic polling, december 2021
POLL: Send [P1467R7] (Extended Floating-Point Types) to Evolution Working Group and Library Working Group for C++23, classified as an addition ([P0592R4] bucket 3 item).
Consensus in favor, forwarded to LWG