Skip to content

[Motions 2023 02 lwg 13] P2679R2 Fixing std::start_lifetime_as and std::start_lifetime_as_array #6114

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 11, 2023
Merged

[Motions 2023 02 lwg 13] P2679R2 Fixing std::start_lifetime_as and std::start_lifetime_as_array #6114

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 24 additions & 4 deletions source/memory.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -881,7 +881,8 @@
\begin{itemdescr}
\pnum
\mandates
\tcode{T} is an implicit-lifetime type\iref{basic.types.general}.
\tcode{T} is an implicit-lifetime type\iref{basic.types.general}
and not an incomplete type\iref{term.incomplete.type}.

\pnum
\expects
Expand Down Expand Up @@ -930,15 +931,34 @@
\end{itemdecl}

\begin{itemdescr}
\pnum
\mandates
\tcode{T} is a complete type.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had the same thoughts during the initial review but never send a comment about this ;-)

Copy link
Contributor Author

@RobertLeahy RobertLeahy Feb 14, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


\pnum
\expects
\tcode{n > 0} is \tcode{true}.
\tcode{p} is suitably aligned for an array of \tcode{T} or is null.
\tcode{n <= size_t(-1) / sizeof(T)} is \tcode{true}.
If \tcode{n > 0} is \tcode{true},
\range{(char*)p}{(char*)p + (n * sizeof(T))} denotes
a region of allocated storage that is
a subset of the region of storage
reachable through\iref{basic.compound} \tcode{p}.

\pnum
\effects
Equivalent to:
\tcode{return *start_lifetime_as<U>(p);}
If \tcode{n > 0} is \tcode{true},
equivalent to
\tcode{start_lifetime_as<U>(p)}
where \tcode{U} is the type ``array of \tcode{n} \tcode{T}''.
Otherwise, there are no effects.

\pnum
\returns
A pointer to the first element of the created array,
if any;
otherwise,
a pointer that compares equal to \tcode{p}\iref{expr.eq}.
\end{itemdescr}

\rSec2[allocator.tag]{Allocator argument tag}
Expand Down