Open brycelelbach opened 1 year ago
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:
Open Questions:
integral_constant
-like or constexpr_t
-like.Topics to Polls:
constexpr_t
variable.constexpr_t
.integral_constant
literals or provide constexpr_t
literals compatible with integral_constant
.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_t
s (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_constant
s (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
End: 14:35
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.
Bring a revision of P2781R0 (integral_constant
Literals and constexpr_t
), with the guidance below, to Library Evolution for further design review.
integral_constant
-like or constexpr_t
-like.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.(merged from issue: https://github.com/cplusplus/papers/issues/1512)
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.constexpr_v
, constexpr_value
, and c_
.constexpr_value
concept.auto
template parameter vs type parameter and value parameter.End: 12:39
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.
Revise the paper and return to Library Evolution:
operator()
instead of operator[]
.constexpr_v
to take a single auto
template parameter instead of a type template parameter and value template parameter.(merged from issue: https://github.com/cplusplus/papers/issues/1512)
P2781R2: constexpr_v
2023-06-12 Library Evolution Minutes
Chair: Nevin Liber, Fabio Fracassi
Champion: Zach Laine
Minute Taker: Guy Davidson
No polls were taken The paper requires more discussion and will be seen again in Kona 2023
The paper requires more discussion and will be seen again in Kona 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.
2022-11-06 Library Evolution Kona 2023 Meeting Minutes
Chair: Fabio Fracassi / Inbal Levi
Champion: Zach Laine, Matthias Kretz
Minute Taker: Andreas Weis
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.
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.
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.
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.
And EWG paper is needed for this paper.
"P2781R4 std::constexpr_wrapper" was scheduled for LEWG telecon on 2024-08-27, however, few fixes and improvements were suggested in the reflector prior to the meeting, including @hanickadot's (https://lists.isocpp.org/lib-ext/2024/08/27771.php) which allows support in string literals. Authors will apply the improvements and publish R5, which will be scheduled for LEWG's review. NOTE: The option to apply a solution similar to the one proposed in P1045 requires exploration but is still on the table for 26.
P2781R0
std::integral_constant
Literals andstd::constexpr_t
(Matthias Kretz, Zach Laine)