2023-02-09 13:00 to 15:15 Issaquah Library Evolution Meeting

P2781R0: integral_constant Literals and constexpr_t

2023-02-09 13:00 to 15:15 UTC-8 Issaquah Library Evolution Minutes

Champion: Zach Laine (IP) & Matthias Kretz (IP)

Chair: Bryce Adelstein Lelbach (IP) & Robert Leahy (IP)

Minute Taker: Steve Downey (IP)

Start: 2023-02-09 13:06 UTC-8

Does this paper have:

• Examples?
  • Yes.
• Field experience?
  • In Boost Hana, but not from specification or in a Standard Library.
• Performance considerations?
  • Not discussed.
• Discussion of prior art?
  • Yes.
• Changes Library Evolution previously requested?
  • Yes.
• Wording?
  • No.
• Breaking changes?
  • No.
• Feature test macro?
  • Will be added with wording.
• Freestanding?
  • Yes.

Open Questions:

• Concept for integral_constant-like or constexpr_t-like.

Topics to Polls:

• Name for constexpr constexpr_t variable.
• Add constexpr_t.
• Provide integral_constant literals or provide constexpr_t literals compatible with integral_constant.
• Provide a constexpr variable template for std::integral_constants.
• constexpr_t::operator() should call operator() on the underlying value.
• constexpr_t operators should work with anything that has a static constexpr value member.
• constexpr_t should have operator() and operator[].
• constexpr_t operator() and operator[] should unwrap.

template <class... Args>
  requires has-static-value<Args>...
    constexpr auto operator()(Args... args) const
      -> constexpr_t<decltype(X(Args::value...)), X(Args::value...)>
        { return {}; }

POLL: constexpr_t should have operator() and operator[] that call the underlying operators with unwrapped values.

Attendance: 19 (in person) + 10 (remote)

# of Authors: 2

Author Position: 2x SF

Outcome: Strong consensus in favor.

POLL: Provide constexpr_t integral literals (quantity and suffix names TBD).

Attendance: 19 (in person) + 10 (remote)

# of Authors: 2

Author Position: 2x N

Outcome: No consensus; we leave it up to the authors discretion.

N: I'd vote WA if the proposal was for just some of the suffixes.

POLL: Provide a constexpr variable template for constexpr_ts (name TBD).

Attendance: 19 (in person) + 10 (remote)

# of Authors: 2

Author Position: 2x SF

Outcome: Strong consensus in favor.

POLL: Provide a constexpr variable template for integral_constants (name TBD).

Attendance: 19 (in person) + 10 (remote)

# of Authors: 2

Author Position: 1x N, 1x SA

Outcome: No consensus; strongly neutral.

SA: It's too confusing to have two.

Name for constexpr constexpr_t variable.

• std::c
• std::co
• std::ct
• std::c_
• std::_C
• std::c_v
• std::cx
• std::cv
• std::v_
• std::_v
• std::cn
• std::con
• std::cnt
• std::cnst
• std::constant
• std::constexpr_v
• All of the above in a nested namespace.

End: 14:35

Summary

This paper proposes constexpr_t, a more general form of integral_constant that provides all of the numeric operations, and user-defined literals for integral constants.

We were generally in favor of the addition of constexpr_t. A good chunk of time was spent discussing the semantics of operator() and operator[], until we eventually reached agreement on what was correct and desirable. We discussed whether we wanted operator() and operator[] to "unwrap", and we determined we did. We also discussed the corner case of constexpr_t of constexpr_t.

We also agreed that we wanted a variable template of type constexpr_t. The paper proposes that such a facility be called std::c, which we had consensus that we wanted. We considered what names might be acceptable for this facility, including possibly putting it in a nested namespace. Our preference seems to be for a shorter name.

We talked about user-defined literals for integral constants, but we did not have consensus to add them.

Finally, we spent some timewe wanted a variable template of type constexpr_t. The paper proposes that such a facility be called std::c, which we had consensus that we wanted. We considered what names might be acceptable for this facility, including possibly putting it in a nested namespace. Our preference seems to be for a shorter name.

Next Steps

Bring a revision of P2781R0 (integral_constant Literals and constexpr_t), with the guidance below, to Library Evolution for further design review.

• Add wording.
• Remove user-defined literals.
• Explore name options.
• Explore adding a concept for integral_constant-like or constexpr_t-like.
• Fix the specification of constexpr_t operator() and operator[] to constrain the arguments to be things with a static value member and to unwrap those values and pass them to the underlying object.

P2781R1 std::constexpr_v (Zach Laine, Matthias Kretz)
(January 2023)

(merged from issue: #1512)

2023-05-16 Library Evolution Telecon

P2781R1: constexpr_v

2023-05-16 Library Evolution Telecon Minutes

Champion: Zach Laine

Chair: Bryce Adelstein Lelbach

Minute Taker: Ben Craig

Start: 2023-05-16 11:03 Eastern

POLL: Add the constexpr_value concept (modulo bikeshedding).

Attendance: 16

# of Authors: 2

Author Position: 1x SF, 1x WF

Outcome: Weak consensus in favor, but this will need to be revisited. Authors should add additional motivation and examples in future revisions.

SA: I think that adding this concept will promote a programming practice that will have worse compilation times (because the concept will be checked everywhere) and will complicate libraries that use it because they have to think about all possible types that satisfy this concept, instead of a single vocabulary type. I'd prefer a vocabulary type.

(Poll taken for the second time, after discussion)

POLL: Add the constexpr_value concept (modulo bikeshedding).

Attendance: 16

# of Authors: 2

Author Position: 2x SF

Outcome: No consensus.

POLL: It would be okay to ship constexpr_v without a constexpr_value concept.

Attendance: 16

# of Authors: 2

Author Position: 1x WF, 1x N

Outcome: Consensus in favor.

WA: I think if we ship without the concept, people will start writing code that just uses the vocabulary type and I think that'll be a mess, and the utility of adding the concept later will decrease.

POLL: The constexpr value type from P2781 should be called constant.

Attendance: 15

# of Authors: 2

Author Position: 1x WF, 1x SA

Outcome:

POLL: The constexpr value type from P2781 should be called constexpr_v.

Attendance: 16

# of Authors: 2

Author Position: 1x WF, 1x SA

Outcome: Weak consensus against.

Poll Ideas:

• constexpr_v call operator vs integral_constant call operator.
• Naming of constexpr_v, constexpr_value, and c_.
• Add the constexpr_value concept.
• Single auto template parameter vs type parameter and value parameter.

End: 12:39

Summary

Much of our discussion revolved around whether we needed a concept for a constexpr value. Some felt strongly that this was necessary to allow people to write functions that can accept either integral_constant or the new type. Others disagreed.

We could not reach a consensus on this matter. We could add the new type now, and add a concept later, but those in favor of a concept feel it is essential to the programming model.

We discussed whether we could make integral_constant convert to the new type, however that is not viable because you cannot deduce the constant template parameter.

We also discussed naming briefly.

Next Steps

Revise the paper and return to Library Evolution:

• Explore new solutions to the concept question that might increase consensus; alternatively but less preferably, provide more compelling evidence to increase consensus for one of the existing positions.
• Fix index operator which is incorrectly written as operator() instead of operator[].
• Change constexpr_v to take a single auto template parameter instead of a type template parameter and value template parameter.

P2781R2 std::constexpr_v (Zach Laine, Matthias Kretz)
(May 2023)

(merged from issue: #1512)

2023-06-12 Library Evolution Varna

P2781R2: constexpr_v

2023-06-12 Library Evolution Minutes

Chair: Nevin Liber, Fabio Fracassi

Champion: Zach Laine

Minute Taker: Guy Davidson

Summary

No polls were taken
The paper requires more discussion and will be seen again in Kona 2023

Next Steps

The paper requires more discussion and will be seen again in Kona 2023

P2781R3 std::constexpr_v (Zach Laine, Matthias Kretz)
(June 2023)

@inbal2l, the merged comment for the 2023-05-16 telecon lists the same poll twice with different results. Was the same poll conducted twice? Or should one of these have different poll wording? The link to the minutes is broken too.

Hi @tahonermann, thanks for noticing! I've updated the link, seems like the poll needs to be fixed in the minutes as well. @brycelelbach, @ben-craig - can you please correct this?

Was the same poll conducted twice? Or should one of these have different poll wording? The link to the minutes is broken too.

It's been a few months, but I believe this poll was taken twice. Whether to add a concept or not garnered a lot of discussion.

It's been a few months, but I believe this poll was taken twice. Whether to add a concept or not garnered a lot of discussion.

Yes, that makes sense, as there was quite a lot of discussion in between. Thanks for the clarification.

Library Evolution Meeting in Kona 2023-11-06

2022-11-06 Library Evolution Kona 2023 Meeting Minutes

Chair: Fabio Fracassi / Inbal Levi

Champion: Zach Laine, Matthias Kretz

Minute Taker: Andreas Weis

Polls

POLL: We should add mutating operations (i.e. #define IF_LEWG_SAYS_SO 1 and ++ and --) to P2781R2

Outcome: Strong consensus in favor

Attendance: 22 IP + 6 R = 28

# of Authors: 2

Authors’ position: SF, N

Outcome: Weak consensus in favor

POLL: We want to proceed with P2781R3 even if a potential core language feature would make this obsolete.

Outcome: Strong consensus in favor

Attendance: 23 IP + 6 R = 29

# of Authors: 2

Authors’ position: SF, SF

Outcome: Weak consensus in favor

SA: Not a high priority, should be in the language. If I see numbers that there is pressing need for having this now, I could be convinced.

Summary

Authors should reach out to EWG and the author of https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1045r1.html, to explore the potential progress as a language feature for C++26.

Outcome

LEWG chair to reach out to EWG chair to schedule a discussion on an evaluation of whether this feature can be implemented in the language, and whether is it possible within the C++26 timeframe.

Evolution Meeting in Kona 2023-11-07

Seen by EWG in Kona 2023 (Full Minutes):

Poll: P2781R3 “std::constexpr_v” and P1045R1 “constexpr Function Parameters” EWG would like to solve the problem solved by std::constexpr_v in the language, for example as proposed by P1045R1 or with “expression aliases”, rather than solving it in library. An implementation is desired. C++26 seems ambitious.

Consensus.

P2781R5 std::constexpr_wrapper (Hana Dusíková, Matthias Kretz, Zach Laine)

2025-01-07 Library Evolution Telecon

P2781R5 std::constexpr_wrapper

2025-01-07 Library Evolution Telecon Minutes

Champion: Zach Laine
Chair: Inbal Levi
Minute Taker: Guy Davidson / Mark Hoemmen

Summary

POLL: Make operator() and operator[] static
Attendance: 21
Outcome: No objection to unanimous consent.

POLL: We would like to pull out the support for string literals and arrays (SUPPORT_ARRAY_VALUES part of the wording removed) from the std::constant_wrapper.

Attendance: 21
Author's Position: N, F
Outcome: Consensus against

ACTIONs:

• Make “adl-type” a note or remove it.
• If integral-constant-like defined in the standard (for example in subclause of submdspan) it needs to be lifted out.
• Explore if “constexpr_params” expo only should be further restricted.
• Apply preferred wording style: template should be modified to “class”
• in operator++ modify: ++c → c++

POLL: Apply the fixes as described above and forward P2781R5 to LWG for C++26.

Attendance: 21
Author's Position: 2xSF
Outcome: Consensus in favor

Next Steps

We’ve approved the added support for strings and the design to support it (adding level of indirection).

The authors will apply the following changes:

• Make operator() and operator[] static
• Wording / bug fixes:
  • Make “adl-type” a note or remove it.
  • If integral-constant-like defined in the standard (for example in subclause of submdspan) it needs to be lifted out.
  • Explore if “constexpr_params” expo only should be further restricted (as it’s expo only, can be done in LWG).
  • Apply preferred wording style: template should be modified to “class”
  • in operator++ modify: ++c → c++

And forward the fixed paper to LWG for C++26 (no electronic poll, as we’re toward the end of the cycle. No objection from the room).

LWG saw this Thursday morning in Hagenberg.

minutes: https://wiki.edg.com/bin/view/Wg21hagenberg2025/LWGThursdayEarlyMorning#p2781

2025-03-11 Library Evolution Telecon

P2781R7: std::constant_wrapper

2025-03-11 Library Evolution Hagenberg Minutes

Champion: Zach Laine
Chair: Fabio Fracassi
Minute Taker: Mark Hoemmen

Summary

POLL: We encourage work on a new paper that discusses replacing nontype with constant_wrappper for C++26.

Attendance: 27
Author's Position: 2xSF
Outcome: Consensus in favor

POLL: Remove “static” from index and call operators.

Attendance: 27
Outcome: No objection to unanimous consent

POLL: Reintroduce the operator, from P2781R6 and define it as deleted (without prejudice).

Attendance: 25
Author's Position: F, SF
Outcome: Consensus in favor

POLL: Add additional is_constructible_v<> constraints to operator&& and operator||. (enable shortcut evaluation for some cases)

Attendance: 25
Outcome: No objection to unanimous consent

POLL: Get rid of operator() -> value_type (not operator() -> cw)

Attendance: 23
Author's Position: 2xSF
Outcome: Strong consensus in favour

ACTION: Remove second definition of cw template (editorial)

POLL: Apply the design changes and send the updated paper P2781R8 back to LWG.

Attendance: 23
Author's Position: 2xSF
Outcome: Consensus in favor

Next Steps

Apply the changes above and send P2781R8 back to LWG for C++26.

P2781R6 std::constexpr_wrapper (Zach Laine, Matthias Kretz, Hana Dusíková)

P2781R7 std::constexpr_wrapper (Zach Laine, Matthias Kretz, Hana Dusíková)

P2781R8 std::constexpr_wrapper (Zach Laine, Matthias Kretz, Hana Dusíková)