[Motions 2023 02 lwg 13] P2679R2 Fixing std::start_lifetime_as and std::start_lifetime_as_array #6114
Conversation
RobertLeahy
force-pushed
the
motions-2023-02-lwg-13
branch
from
9623843 to
1e2f334
Compare
|
This also fixes cplusplus/papers#1345. |
|
Thank you! |
| @@ -927,15 +928,33 @@ | |||
| \end{itemdecl} | |||
|
|
|||
| \begin{itemdescr} | |||
| \pnum | |||
| \mandates | |||
| \tcode{T} is a complete type. | |||
There was a problem hiding this comment.
I know this is what the approved paper says, but is there any reason that the non-array form requires "not an incomplete type" and the array form requires "is a complete type"? It seems like they could both say it the same way.
There was a problem hiding this comment.
I had the same thoughts during the initial review but never send a comment about this ;-)
There was a problem hiding this comment.
Doing a quick search through the draft I see both forms used elsewhere in the standard. I'm unsure if the distinction was deliberate since I don't precisely remember the details of the completeness discussion in Core in Kona.
Interestingly "T is a complete type" doesn't seem to come with a cross reference elsewhere whereas "T is not an incomplete type" does seem to (to term.incomplete.type) which I'll add to this PR in the next revision.
There was a problem hiding this comment.
We're a bit inconsistent in the library. Core folk will tell you that we don't define the term "complete type", we only define "incomplete type". Library insists that we can use "complete type" with the obvious English-language meaning "a type which is not an incomplete type", so you will sometimes see "complete type" and sometimes "not an incomplete type".
There was a problem hiding this comment.
Is it therefore fine for this change to be internally inconsistent (as specified in the paper) or can/should we editorially coalesce around "complete type" or "not an incomplete type" consistently?
There was a problem hiding this comment.
I'd prefer to have LWG come back with some guidance, and we'll take the paper as approved for now. But it's a good question worth settling, @jwakely.
RobertLeahy
force-pushed
the
motions-2023-02-lwg-13
branch
from
1e2f334 to
f2ee36c
Compare
|
Hey guys, I signed up for this motion at #6103. My commit is in motions-2023-02-lwg-13. Please follow our process - you need to sign up for the github issue before taking the motion to avoid duplicate work. I didn't notice this "fix" for the issue when I signed up for it. Alas. |
RobertLeahy
force-pushed
the
motions-2023-02-lwg-13
branch
from
f2ee36c to
4264251
Compare
|
@burblebee Very sorry about that, we'll make this clearer next time! |
Fixes NB CA 086, US 088 (C++23 CD).
tkoeppe
force-pushed
the
motions-2023-02-lwg-13
branch
from
4264251 to
6a73de7
Compare
tkoeppe
dismissed
jwakely’s stale review
Out of scope, please advise with LWG guidance in separate issue/PR.
Fixes #6103.
Fixes cplusplus/nbballot#459.
Fixes cplusplus/nbballot#508.
Fixes cplusplus/papers#1345.