P2781 R8 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)