Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

P1467 Extended floating-point types and standard names #227

Open
jensmaurer opened this issue Jan 26, 2019 · 24 comments
Open

P1467 Extended floating-point types and standard names #227

jensmaurer opened this issue Jan 26, 2019 · 24 comments

Comments

@jensmaurer
Copy link
Member

@jensmaurer jensmaurer commented Jan 26, 2019

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

@Lawrence-Crowl
Copy link

@Lawrence-Crowl Lawrence-Crowl commented Feb 20, 2019

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
Copy link
Collaborator

@jfbastien jfbastien commented Feb 24, 2019

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

@jfbastien jfbastien removed this from the 2019-02 milestone Feb 24, 2019
@jfbastien jfbastien added this to the 2019-07 milestone Feb 24, 2019
@wg21bot
Copy link
Collaborator

@wg21bot wg21bot commented Jun 23, 2019

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

@jensmaurer jensmaurer added this to Tuesday in EWG-I in Cologne 2019 Jul 11, 2019
@brycelelbach
Copy link
Collaborator

@brycelelbach brycelelbach commented Jul 16, 2019

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
Copy link
Collaborator

@jfbastien jfbastien commented Jul 18, 2019

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.

@jensmaurer jensmaurer removed this from the 2019-07 milestone Aug 23, 2019
@jensmaurer jensmaurer added this to the 2019-11 milestone Aug 23, 2019
@AaronBallman
Copy link
Collaborator

@AaronBallman AaronBallman commented Oct 7, 2021

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.

@AaronBallman AaronBallman removed the SG22 label Oct 7, 2021
@erichkeane
Copy link
Collaborator

@erichkeane erichkeane commented Oct 21, 2021

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
Copy link
Collaborator

@wg21bot wg21bot commented Oct 26, 2021

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

@brycelelbach
Copy link
Collaborator

@brycelelbach brycelelbach commented Nov 15, 2021

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
Copy link
Collaborator

@wg21bot wg21bot commented Nov 26, 2021

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

@wg21bot
Copy link
Collaborator

@wg21bot wg21bot commented Nov 26, 2021

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

@erichkeane
Copy link
Collaborator

@erichkeane erichkeane commented Dec 16, 2021

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
Copy link
Collaborator

@wg21bot wg21bot commented Dec 18, 2021

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

@jensmaurer jensmaurer removed this from the 2021-telecon milestone Jan 1, 2022
@jensmaurer jensmaurer added this to the 2022-telecon milestone Jan 1, 2022
@cor3ntin
Copy link
Collaborator

@cor3ntin cor3ntin commented Jan 16, 2022

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

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

Consensus in favor, forwarded to LWG

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet