[2026-03 LWG Motion 20] P4022R0 Remove try_append_range from inplace_vector for now#8896
[2026-03 LWG Motion 20] P4022R0 Remove try_append_range from inplace_vector for now#8896eisenwave wants to merge 2 commits intocplusplus:mainfrom
try_append_range from inplace_vector for now#8896Conversation
eisenwave
force-pushed
the
motions-2026-03-lwg-20
branch
from
1645dbb to
f074e2f
Compare
source/support.tex
Outdated
| #define @\defnlibxname{cpp_lib_initializer_list}@ 202511L | ||
| // freestanding, also in \libheader{initializer_list} | ||
| #define @\defnlibxname{cpp_lib_inplace_vector}@ 202406L // also in \libheader{inplace_vector} | ||
| #define @\defnlibxname{cpp_lib_inplace_vector}@ 202603L // also in \libheader{inplace_vector} |
There was a problem hiding this comment.
The paper depicted __cpp_lib_constexpr_inplace_vector being updated, which made no sense to me (the change has nothing to do with constexprization). Updating the original macro __cpp_lib_inplace_vector makes much more sense. I'd like to confirm that this is everyone's expectation.
There was a problem hiding this comment.
It did?! Honestly, when I first drafted the PR, I proof-read the changes and thought I smoked the wrong herb when I updated __cpp_lib_constexpr_inplace_vector.
I guess the initial version of this PR was the faithful paper translation ...
@jwakely thoughts? I really wouldn't want this silly feature bump to make it in, and I think we have some editorial freedom for feature testing.
There was a problem hiding this comment.
Also @brevzin since you're at the top of the author list
There was a problem hiding this comment.
#8898 applying P3981R2 has to increase the original macro anyways, so the only question is whether the constexpr macro should be changed, really.
There was a problem hiding this comment.
Updating the original macro
__cpp_lib_inplace_vectormakes much more sense. I'd like to confirm that this is everyone's expectation.
Ugh, yes. This should definitely change __cpp_lib_inplace_vector not __cpp_lib_constexpr_inplace_vector. I wrote this paper in a hurry and I guess I just searched for inplace_vector in [version.syn] and picked the first one and didn't really think much of it.
It did?! Honestly, when I first drafted the PR, I proof-read the changes and thought I smoked the wrong herb
Can you please just stop commenting stuff like this?
There was a problem hiding this comment.
Alright, I'll separate the feature-test change into a separate commit since that's a change to the paper. Since motion 19 is applied first, it looks like that commit would only revert the change made to __cpp_lib_constexpr_inplace_vector after rebasing then, since the bump to __cpp_lib_inplace_vector becomes vacuous.
…to 202502L Updating __cpp_lib_constexpr_inplace_vector instead of __cpp_lib_inplace_vector is an editorial error in the paper; updating __cpp_lib_inplace_vector was intended. P3981R2 already changes the value of __cpp_lib_inplace_vector as part of the same motions.
eisenwave
force-pushed
the
motions-2026-03-lwg-20
branch
from
f074e2f to
ebd8d57
Compare
3 participants
Fixes #8854
Also fixes cplusplus/papers#2655