P2781 R4 std::constexpr_wrapper

[brycelelbach]

P2781R0 std::integral_constant Literals and std::constexpr_t (Matthias Kretz, Zach Laine)

[brycelelbach]

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.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
6	6	4	0	0

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

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

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

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
7	9	1	0	0

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

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

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.

[inbal2l]

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

[inbal2l]

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

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
1	7	3	1	1

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

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

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.

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

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.

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

Attendance: 15

# of Authors: 2

Author Position: 1x WF, 1x SA

Outcome:

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

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

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.

[inbal2l]

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

[inbal2l]

(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

[inbal2l]

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

[tahonermann]

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

[inbal2l]

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?

[ben-craig]

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.

[inbal2l]

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.

[jfbastien]

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

SF	F	N	A	SA
2	6	5	2	0

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.

SF	F	N	A	SA
6	9	4	2	1

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.

SF	F	N	A	SA
6	8	5	1	0

Consensus.

[inbal2l]

Waiting for input from an EWG participant to author + implement the language feature.
(a good candidate for such is the paper P1045 (issue) which requires a new revision)

[wg21bot]

P2781R4 std::constexpr_wrapper (Zach Laine, Matthias Kretz)

[jfbastien]

And EWG paper is needed for this paper.