P2337 Less constexpr for <cmath>

[wg21bot]

P2337R0 Less constexpr for <cmath> (Nicholas G Timmons)

[brycelelbach]

2021-05-17 Library Evolution Telecon

P0533R7: constexpr for <cmath>

2021-05-17 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Oliver Rosten

Minute Taker: Ben Craig

Start: 2021-05-17 08:05 Pacific

One of the objections to moving forward with this at plenary was lack of field experience. Some were saying that they wanted this, but were concerned that we needed more field experience to prove it's implementable.

Q: Does P0533 have implementation experience?

A: Yes - GCC has an implementation that has been shipping for some time. There has been some question about it's maturity. The author of P0533 has done an evaluation and believes it actually gives the correct answer in most cases: https://godbolt.org/z/b3vhqT7dK

A lot of the concern is about what happens when these functions are evaluated at constexpr time.

Author suggests that something that might be allowed at runtime and produce an error, but be forbidden at compile time - for example, feeding something a NaN may raise a flag at runtime, but could be forbidden at compile time.

Q: What does the GCC implementation do for these failure cases at constexpr time today?

A: It rejects the failure cases.

Q: Does the current design and wording reflect that?

A: Yes. "A call to a C standard library function that encounters a domain error or overflow is not a core constant expression." We may need to make it clear that pole errors and underflow errors are not allowed at constexpr time.

It may not be clear when a function encounters an error that would set errno or set a flag. C's Annex F tries to describe this.

Different implementations may have different answers for whether something is an error, so there may be divergence in what constexpr evaluations different implementations allow.

There's some suggestion that we specify the constexpr math environment more (i.e. C's Annex F, IEEE 754), even if that causes divergence with the runtime.

We should make it clear that errno will never be set at constexpr time.

Topics to Polls:

• Disallow all errors at constexpr time.
• Divergence between constexpr and runtime behavior.
• Divergence between implementations: Is it acceptable for some implementations to allow certain cases at constexpr time and other implementations to reject those cases?

POLL: constexpr evaluations of <cmath> functions that would result in an error that would set errno when math_errhandling & MATH_ERRNO is true should not compile.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
11	8	0	0	0

Attendance: 28

# of Authors: 1

Author Position: SF

Outcome: That has unanimous consensus in favor.

POLL: For applicable floating point types, constexpr evaluations of the <cmath> functions in P0533 should follow C's Annex F.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
7	8	3	0	0

Attendance: 28

# of Authors: 1

Author Position: SF

Outcome: That has strong consensus in favor.

POLL: Modify P0533R7 (constexpr for <cmath>) by clarifying the error handling as directed by prior polls, and then send the revised paper to Library for C++23 with priority B3 (to be confirmed with a Library Evolution electronic poll).

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
8	8	2	0	0

Attendance: 28

# of Authors: 1

Author Position: SF

Outcome: That has strong consensus in favor.

N: This feels like a lot of changes going into this paper without another Library Evolution meeting. If we didn't have the electronic polling as an intermediate step, I'd probably have been against, but with it, I think we'll have sufficient time for another review.

Author should include expand discussion of field experience in next draft.

End: 09:27

Summary

We discussed how we should handle errors during constant evaluation of the <cmath> functions that P0533 proposes to make constexpr. There was concern that the current design and specification was imprecise and left room for implementation divergence. It was unclear whether the current design would require errno to be set at constexpr time, which is not possible.

To rectify this, we decided that evaluating the proposed <cmath> functions at constexpr time should always be ill-formed when an error is encountered. We also decided to tie the semantics of constexpr evaluations of these functions to C's Annex F to ensure clear and consistent semantics for these edge cases.

Outcome

Library Evolution sends P0533R7 (constexpr for <cmath>), with the guidance below, to Library, for C++23, classified as new work (P0592 bucket 3 item). This will be confirmed via a Library Evolution electronic poll.

• Make constexpr evaluations of the proposed <cmath> functions that would result in an error that would set errno when math_errhandling & MATH_ERRNO ill-formed.
• Make constexpr evaluations of the proposed <cmath> functions follow C's Annex F for all applicable floating point types.

[brycelelbach]

2021-06-28 Library Evolution Telecon

P1383R0: More constexpr for <cmath>

P2337R0: Less constexpr for <cmath>

2021-06-28 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Oliver Rosten (P1383) and Nicholas Timmons (P2337)

Minute Taker: Ben Craig

POLL: We should promise more committee time to pursuing P1383 (More constexpr for <cmath> and <complex>), knowing that our time is scarce and this will leave less time for other work (is this the right time)

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
3	10	6	2	0

Attendance: 25

# of Authors: 1

Author Position: SF

Outcome: Consensus

POLL: P1383 constexpr <cmath>/<complex> functions with correct rounding should have different names than C.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
4	7	6	1	1

Attendance: 24

# of Authors: 1

Author Position: Neutral

Outcome: Preference for different names, authors will investigate, not binding

SA: constexpr vs. non-constexpr is the wrong dimension to pick these apart. If we can't mandate a better impl of current cmath functions, then maybe it's worth introducing new ones.

POLL: P1383 constexpr <cmath>/<complex> functions with new names should have the same behavior at compile time and runtime (if they have runtime behavior).

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
8	5	4	0	0

Attendance: 23

# of Authors: 0

Author Position: Not present.

Outcome: Author should investigate.

TODO (@billy-baker)

Summary

TODO (@billy-baker)

Outcome

TODO (@billy-baker)

[brycelelbach]

Closing due to more than 1 year of inactivity. Please re-open if further work is expected.

This would need to be updated to reflect the progress on P1383 (#168); said progress may decrease the relevancy of this paper.