Skip to content

[containers] Rephrase deduction guide constraints #1548

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

Closed
wants to merge 1 commit into from
Closed

[containers] Rephrase deduction guide constraints #1548

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
71 changes: 40 additions & 31 deletions source/containers.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -700,6 +700,31 @@

\end{libreqtab4a}

\pnum
In this Clause the behavior of certain member functions and deduction guides
Copy link
Contributor

Choose a reason for hiding this comment

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

...and Clause~\ref{strings}. Also need to update the cross reference in [string.cons] after the move.

Copy link
Contributor

Choose a reason for hiding this comment

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

While we are in the vicinity, basic_string's deduction guide specification is missing a \pnum.

Copy link
Member Author

@jwakely jwakely Mar 18, 2017 •
edited
Loading

Choose a reason for hiding this comment

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

The missing \pnum is fixed.

depends on whether types qualify as input iterators or allocators.
The extent to which an implementation determines that a type cannot be an input
iterator is unspecified, except that as a minimum integral types shall not qualify
as input iterators.
Likewise, the extent to which an implementation determines that a type cannot be
an allocator is unspecified, except that as a minimum a type \tcode{A} shall not qualify
as an allocator unless it satisfies both of the following conditions:

\begin{itemize}
\item The \grammarterm{qualified-id} \tcode{A::value_type}
is valid and denotes a type~(\ref{temp.deduct}).

\item The expression \tcode{declval<A\&>().allocate(size_t\{\})}
is well-formed when treated as an unevaluated operand.
\end{itemize}

\pnum
\begin{note}
Copy link
Member

Choose a reason for hiding this comment

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

I don't like this note as-written: it suggests that implementations can impose unbounded constraints on the types in questions, rather than merely constraints that are derivable from the allocator or input iterator requirements.

I'm inclined to merge this without the new note.

Implementations may impose additional conditions which must be satisfied
to qualify as an input iterator or an allocator.
\end{note}


\rSec2[container.requirements.dataraces]{Container data races}

\pnum
Expand Down Expand Up @@ -1002,26 +1027,10 @@
shall not participate in overload resolution.

\item A deduction guide for a sequence container shall not participate in overload resolution
if it has an \tcode{InputIterator} template parameter that is called with a type that does not
qualify as an input iterator,
or if it has an \tcode{Allocator} template parameter that is called with a type that does not
qualify as an allocator.
\end{itemize}

\pnum
The extent to which an implementation determines that a type cannot be an input
iterator is unspecified, except that as a minimum integral types shall not qualify
as input iterators.
Likewise, the extent to which an implementation determines that a type cannot be
an allocator is unspecified, except that as a minimum a type \tcode{A} not satisfying
both of the following conditions shall not qualify as an allocator:

\begin{itemize}
\item The \grammarterm{qualified-id} \tcode{A::value_type}
is valid and denotes a type~(\ref{temp.deduct}).

\item The expression \tcode{declval<A\&>().allocate(size_t\{\})}
is well-formed when treated as an unevaluated operand.
if it has an \tcode{InputIterator} template parameter and a type that does not
Copy link
Contributor

@timsong-cpp timsong-cpp Mar 16, 2017 •
edited
Loading

Choose a reason for hiding this comment

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

Hmm, does has a template parameter named \tcode{InputIterator} sound better?

qualify as an input iterator is deduced for that parameter,
or if it has an \tcode{Allocator} template parameter and a type that does not
qualify as an allocator is deduced for that parameter.
\end{itemize}

\pnum
Expand Down Expand Up @@ -2038,13 +2047,13 @@
if any of the following are true:
\begin{itemize}
\item It has an \tcode{InputIterator} template parameter
that is called with a type that does not qualify as an input iterator.
and a type that does not qualify as an input iterator is deduced for that parameter.

\item It has an \tcode{Allocator} template parameter
that is called with a type that does not qualify as an allocator.
and a type that does not qualify as an allocator is deduced for that parameter.

\item It has a \tcode{Compare} template parameter
that is called with a type that qualifies as an allocator.
and a type that qualifies as an allocator is deduced for that parameter.
\end{itemize}

\indextext{associative containers!exception safety}%
Expand Down Expand Up @@ -2871,16 +2880,16 @@
if any of the following are true:
\begin{itemize}
\item It has an \tcode{InputIterator} template parameter
that is called with a type that does not qualify as an input iterator.
and a type that does not qualify as an input iterator is deduced for that parameter.

\item It has an \tcode{Allocator} template parameter
that is called with a type that does not qualify as an allocator.
and a type that does not qualify as an allocator is deduced for that parameter.

\item It has a \tcode{Hash} template parameter
that is called with an integral type or a type that qualifies as an allocator.
and an integral type or a type that qualifies as an allocator is deduced for that parameter.

\item It has a \tcode{Pred} template parameter
that is called with a type that qualifies as an allocator.
and a type that qualifies as an allocator is deduced for that parameter.
\end{itemize}

\rSec3[unord.req.except]{Exception safety guarantees}
Expand Down Expand Up @@ -9164,10 +9173,10 @@
\pnum
A deduction guide for a container adaptor shall not participate in overload resolution if any of the following are true:
\begin{itemize}
\item It has an \tcode{InputIterator} template parameter that is called with a type that does not qualify as an input iterator.
\item It has a \tcode{Compare} template parameter that is called with a type that qualifies as an allocator.
\item It has a \tcode{Container} template parameter that is called with a type that qualifies as an allocator.
\item It has an \tcode{Allocator} template parameter that is called with a type that does not qualify as an allocator.
\item It has an \tcode{InputIterator} template parameter and a type that does not qualify as an input iterator is deduced for that parameter.
\item It has a \tcode{Compare} template parameter and a type that qualifies as an allocator is deduced for that parameter.
\item It has a \tcode{Container} template parameter and a type that qualifies as an allocator is deduced for that parameter.
\item It has an \tcode{Allocator} template parameter and a type that does not qualify as an allocator is deduced for that parameter.
\item It has both \tcode{Container} and \tcode{Allocator} template parameters, and \tcode{uses_allocator_v<Container, Allocator>} is \tcode{false}.
\end{itemize}

Expand Down