P1467 Extended floating-point types and standard names

[jensmaurer]

P1467R0 Extended floating-point types (Michał Dominiak, David Olsen)

[Lawrence-Crowl]

SG6: Define narrowing conversions on rank instead of finite value ranges? SF 2 F 3 N 1 A 0 SA 0

Make rank of overlapped ranges unordered. SF 2 F 3 N 1 A 0 SA 0

Make operations on unordered ranks ill-formed. SF 3 F 3 N 0 A 0 SA 0

[jfbastien]

Lots of feedback in EWG-I in Kona. Want to see again. LEWGI should see this too.

[wg21bot]

P1467R1 Extended floating-point types (Michał Dominiak, David Olsen)

[brycelelbach]

Cologne 2019-07 LEWGI Minutes

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?

Put the num_put/num_get ABI breaks on Titus' list of ABI breaks.

Cologne 2019-07 LEWGI Minutes

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 float, double, and long double.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
4	13	4	1	0

Attendance: 26

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.

Attendance: 25

POLL: Forward P1467R0 (with the addition of support for extended floating point types in <atomic> and <random>) and P1468R0 to LEWG for C++23.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
2	15	5	1	0

A: Want to see more implementation experience.

Attendance: 25

End: 12:04

CONSENSUS: Forward P1467R0 (with the addition of support for extended floating point types in <atomic> and <random>) and P1468R0 to LEWG for C++23.

[jfbastien]

EWGI in Cologne (seen with #228):

The extended floating-point types should be allowed to alias float/double/long double. SF F N A SA 1 2 2 4 3 Forward the papers to EWG + LEWG. SF F N A SA 3 9 0 0 0

Note one of the above polls reverse a LEWGI poll.

Send to EWG + LEWG.

[wg21bot]

P1467R2 Extended floating-point types (Michał Dominiak, David Olsen)

[jfbastien]

EWG saw P1467 and P1468 at the same time. http://wiki.edg.com/bin/view/Wg21belfast/P1467-EWG http://wiki.edg.com/bin/view/Wg21belfast/P1468-EWG

1. Allow (lossy) implicit conversion for the new extended floating-point types from larger to smaller

SF	F	N	A	SA
2	3	5	7	0

2. Should floating-point aliases be optional?

SF	F	N	A	SA
4	5	2	3	1

3. Assuming types aren’t optional, should we mandate using std::float32_t = float; using float64_t = double;

SF	F	N	A	SA
0	1	3	1	8

4. Assuming types aren’t optional, should we mandate using std::float128_t = long double;

SF	F	N	A	SA
0	0	3	0	10

5. Assuming aliasing double isn’t mandated, should std::float_t and others be allowed to alias double and others?

SF	F	N	A	SA
2	2	3	3	3

6. EWG would like to see P1467 and P1468 again?

SF	F	N	A	SA
7	10	2	1	0

[wg21bot]

P1467R3 Extended floating-point types (David Olsen, Michał Dominiak)

[tituswinters]

These are going to EWG before LEWG, dropping the LEWG label.

[jfbastien]

EWG in Prague saw this Tuesday afternoon with P1468 (https://github.com/cplusplus/papers/issues/228).

EWG in Prague saw this Tuesday afternoon with P1467 (https://github.com/cplusplus/papers/issues/227).

The new floatX_t types aren’t aliases for float / double / long double, they are independent types.	SF	F	N	A	SA
23	13	0	2	0

Allow implicit conversion between floatX_t and float / double / long double (i.e. pointers to the basic types) as a transition tool, only when they are representation compatible.	SF	F	N	A	SA
0	4	7	18	8

Extended floating point types match the current C++ rules for conversions.	SF	F	N	A	SA
2	3	6	19	3

Implicit conversions are only allowed if non-narrowing.	SF	F	N	A	SA
14	15	8	0	1

Don’t do anything implicitly (as opposed to matching the current C++ rules or tuning them).	SF	F	N	A	SA
2	7	6	14	4

Prefer smaller safe conversions over larger safe conversions in overload resolution.	SF	F	N	A	SA
3	14	10	0	7

Only add float16_t and bfloat16_t, don’t add float32_t / float64_t / float128_t.	SF	F	N	A	SA
0	5	17	10	3

[wg21bot]

P1467R4 Extended floating-point types and standard names (David Olsen, Michał Dominiak)

[jfbastien]

P1468 was merged into this one, see https://github.com/cplusplus/papers/issues/228 for its history.

[jfbastien]

EWG telecon today:

Prefer smaller safe conversions over larger safe conversions in overload resolution (proposal in the paper, polled in Prague).	SF	F	N	A	SA
0	8	3	4	1

Overload resolution should stay the same, two different safe conversions should remain ambiguous (keep the current status-quo).	SF	F	N	A	SA
5	4	3	4	1

Adding back LEWG since the above is our last big unresolved Language question, and Library can operate without it being fully resolved (since they'll provide precise overloads regardless of what we go for).

[ben-craig]

P1467R4: Extended floating-point types and standard names

P1467R4: Extended floating-point types and standard names

2020-08-10 Library Evolution Telecon Minutes

Chair: Ben Craig

Champion: David Olsen

Minute Taker: Mark Hoemmen, Guy Davidson

Start: 2020-08-10 10:00AM Central Daylight Time (US)

End: 11:30AM

SUMMARY: Do research, incorporate feedback, and come back with another revision.

The chair recommends determining and reporting on the limitations of iostreams with extended floating point type. For example, can using the existing virtual methods for double provide satisfactory results?

Math functions with extreme precision can be very difficult to implement, so be sure to have an implementation in hand before we merge this.

The chair recommends listing prior work in the field that this is standardizing.

OUTCOME: POLL: Require printing and formatting functions as part of this paper.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
2	4	5	3	2

Attendance: 21

# of Authors: 1

Author Position: N

Outcome: No consensus. More implementation / field experience is a potential way to increase consensus.

[AaronBallman]

Adding to the SG22 plate for naming and header file discussions related to the types coming from TS 18661 in WG14.

[AaronBallman]

This was at the Oct 6, 2021 special SG22 session.

POLL: Should the usual arithmetic conversions in C++ follow the rules in C?	Committee	SF	F	N	A	SA	Notes
WG14	0	6	0	0	0	Consensus
WG21	2	3	2	2	0	Weak consensus, Authors were 1:F, 2:N

Consensus. Weak on the WG21 side.

POLL: Should the C implicit conversion rules change to follow the rules as proposed for C++?	Committee	SF	F	N	A	SA	Notes
WG14	0	0	0	2	2	No consensus
WG21	2	5	0	2	0	Consensus, Authors were 2:F, 1:A

No consensus.

POLL: Should the _Float C names be available (through some means) in C++ and be used as the types behind the std::float aliases?	Committee	SF	F	N	A	SA	Notes
WG14	5	1	0	0	0	Consensus
WG21	2	2	3	0	2	Weak consensus, Authors were 1:F, 2:N

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?	Committee	SF	F	N	A	SA	Notes
WG14	2	3	0	0	0	Consensus
WG21	2	2	1	3	1	No consensus, Authors were 3:A

SA vote rationale: Similar reasoning for the previous poll. Should there be an alias at all?

No consensus.

Removing from the SG22 plate.

[erichkeane]

Discussed at the EWG Teleon on October 21, 2021

EWG approves the direction on overload resolution as presented in D1467R6.

SF	F	N	A	SA
3	7	3	0	0

Result: Consensus.
We intend to see this paper again once the wording is updated to include references to C23's Annex F, and has been reviewed by a wording expert.

[wg21bot]

P1467R5 Extended floating-point types and standard names (David Olsen, Michał Dominiak, Ilya Burylov)

[brycelelbach]

2021-11-15 Library Evolution Telecon

P1467R6: Extended floating-point types and standard names

2021-11-15 Library Evolution Telecon Minutes

Chair: Fabio Fracassi

Champion: David Olsen

Minute Taker: Mark Hoemmen & Bronek Kozicki

Chair Notes

Does this proposal have:

• Examples? no
• Implementation experience? no
• Usage experience? no
• Deployment experience? no
• Performance considerations? yes
• Discussion of prior art? yes
• Changes Library Evolution previously requested? yes
• Wording? yes
• Feature test macro? yes

Open Questions:

Finer grained feature test macros

Topics to Poll:

POLL: Should we require the C names (_Float16, etc...) to be available	SF	F	N	A	SA
1	1	6	10	1

Participants: 25 Outcome: Consensus Against

POLL: The literal suffixes should be a core language feature.	SF	F	N	A	SA
9	5	4	1	0

Participants: 25 Outcome: Strong Consensus in favor

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).	SF	F	N	A	SA
5	9	1	1	1

Participants: 22 Outcome: Consensus in favor

Summary

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 std namespace as alias to unnamed but distinct (from existing) floating point types. We discussed complexity of implementing the new overloads, especially for [from|to]_chars. Some functions will not get overloads, most notably to_string and iostreams.

Outcome

We decided that the literals should be implemented in the core language instead of the library (subject to EWG approval). There will be a mailing list review of the feature test macros (to enable library implementers to implement the different parts in the own pace). Pending this we forwarded the paper to electronic polling, and to EWG.

[wg21bot]

P1467R6 Extended floating-point types and standard names (David Olsen, Michał Dominiak, Ilya Burylov)

[wg21bot]

P1467R7 Extended floating-point types and standard names (David Olsen, Michał Dominiak, Ilya Burylov)

[erichkeane]

EWG discussed D1467R8 at the December 16, 2021 telecon.

The following poll was taken:

Send D1467R8 to electronic polling for forwarding to CWG for inclusion in C++23, in Bucket 3:	SF	F	N	A	SA
2	5	4	1	0

Result: Consensus

[wg21bot]

P1467R8 Extended floating-point types and standard names (David Olsen, Michał Dominiak, Ilya Burylov)

[cor3ntin]

2021-12 Library Evolution Electronic Poll Outcomes

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

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
10	15	0	2	0

Consensus in favor, forwarded to LWG

[jensmaurer]

CWG telecon 2022-02-25: Partially reviewed.

[jfbastien]

2022-02 poll results:

SF	F	N	A	SA
11	15	2	1	0

Abstain: 16

Poll outcome:✅ consensus

[jensmaurer]

CWG telecon 2022-03-11: Partially reviewed.

[jensmaurer]

CWG telecon 2022-03-25: Reviewed D1467R9; two small updates have been requested.

[jensmaurer]

CWG telecon 2022-04-08: Reviewed updated D1467R9; an update regarding the phrasing for floating-point types as vendor extensions has been requested.

[jensmaurer]

CWG telecon 2022-04-22: Approved D1467R9 for plenary vote.

[JeffGarland]

I"m noticing the LWG notes didn't get added here.

https://wiki.edg.com/bin/view/Wg21telecons2022/P1467-20220225 https://wiki.edg.com/bin/view/Wg21telecons2022/P1467-20220325 https://wiki.edg.com/bin/view/Wg21telecons2022/P1467-20220401

LWG saw this over 3 sessions and asked for various refinements that were made -- culminating in a vote on 2022-04-01

P1467r9 to be sent to Core for inclusion into C++23 with the small amendment discussed?

F	A	N
12	0	0

[wg21bot]

P1467R9 Extended floating-point types and standard names (David Olsen, Michał Dominiak, Ilya Burylov)

[JeffGarland]

@jensmaurer and @jwakely -- did we decide if this is CWG or LWG motion?

[dkolsen-pgi]

@jensmaurer and @jwakely agreed that this paper would be a CWG motion, since the core changes are more significant than the library changes.

[jensmaurer]

It's on the list of CWG proto-motions:

https://wiki.edg.com/bin/view/Wg21telecons2022/StagingForPlenaryStrawPolls