P2772 std::integral_constant literals do not suffice - constexpr_t?

[brycelelbach]

P2772R0 std::integral_constant literals do not suffice - constexpr_t? (Matthias Kretz)

[brycelelbach]

2023-01-17 Library Evolution Telecon

P2725R0: integral_constant Literals

P2772R0: constexpr_t

2023-01-17 Library Evolution Telecon Minutes

Champion: Zach Laine (P2725) & Matthias Kretz (P2772)

Chair: Bryce Adelstein Lelbach

Minute Taker: Ben Craig

Start: 2023-01-17 12:03 Eastern

Does this paper have:

• Examples?
  • Yes.
• Field experience?
  • Implementation experience?
    • Yes, in Boost Hana (not from spec) and in a reference implementation:
      https://github.com/tzlaine/ic_literals
  • Usage experience?
    • Yes, in Boost Hana (not from spec).
  • Deployment experience?
    • Yes, in Boost Hana (not from spec).
• Wording?
  • Yes.
• Breaking changes?
  • Possibly, as it adds unary operator- to integral_constant.
• Feature test macro?
  • Yes.
• Freestanding?
  • Yes.

Open Questions:

• Should we add operator- to integral_constant to support writing negative integral constants with UDLs?
• Could we instead extend the language to support this (e.g. preserving constexprness in parameters)?

POLL: Given what we know today, we're comfortable adding things to integral_constant to support integral constant literals.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
1	7	2	2	1

Attendance: 19

# of Authors: 1

Author Position: WF

Outcome: No consensus.

POLL: Assuming we do add things to integral_constant to support integral constant literals, only add unary operator-.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
0	3	5	3	1

Attendance: 19

# of Authors: 1

Author Position: WF

Outcome: No consensus.

POLL: Add a new robust integral constant type with all the numerical operators, as proposed in P2772R0, and use that for these literals instead of integral_constant.

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

Attendance: 19

# of Authors: 1

Author Position: SF

Outcome: Consensus in favor.

SA: I'd be in favor if the poll didn't say "integral".

Typos:

• In P2725 section 4: "when the number is parsed is > numberic_limits<T>::max()", should say "numeric" instead of "numberic".

End: 12:35

Summary

We discussed proposals for adding integral constant literals to C++.

One paper, P2725, took a minimal approach, simply adding literals of integral_constant type and slightly modifying integral_constant. The other paper, P2772, suggest that we should instead add a new robust constant type with all numerical operations, and use that type for literals instead.

Some raised concerns about the verbosity of the proposed suffixes. There were also suggestions that this problem might be better solved by a language feature.

Next Steps

The authors of P2725 and P2772 will join forces to produce a new joint paper and return to Library Evolution for further review.

[cor3ntin]

Superseded by #1458