Skip to content

[iterator.concept.winc] Move concept definition near its description #4487

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.

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
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
103 changes: 52 additions & 51 deletions source/iterators.tex
Original file line number Diff line number Diff line change
Expand Up @@ -1319,20 +1319,10 @@

template<class T>
inline constexpr bool @\exposid{is-signed-integer-like}@ = @\seebelow@; @\itcorr[-2]@ // \expos

template<class I>
concept @\deflibconcept{weakly_incrementable}@ =
@\libconcept{movable}@<I> &&
requires(I i) {
typename iter_difference_t<I>;
requires @\exposid{is-signed-integer-like}@<iter_difference_t<I>>;
{ ++i } -> @\libconcept{same_as}@<I&>; // not required to be equality-preserving
i++; // not required to be equality-preserving
};
\end{codeblock}
Copy link
Contributor

Choose a reason for hiding this comment

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

Hm, it's a bit weird to have these "bare" codeblocks, which in reality are stuck to their preceding paragraph. The status quo was sort of OK, but the new codeblock you're now introducing below seems to be stuck to the wrong paragraph now. We're lacking a mechanism to introduce something with an unnumbered block at the beginning. We have that for synopses and for grammar, and I suppose for itemdecls, but this use case is none of these. Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

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

FWIW, I wouldn't mind if all of these concept definitions were changed to use itemdecl instead of codeblock. I'm not sure how we landed on codeblock in the first place; I suspect it was a typo on my part the first time that was then replicated a couple of dozen times.

Copy link
Member Author

Choose a reason for hiding this comment

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

Rebased. I've also moved the \pnum to before the codeblock.

Copy link
Contributor

Choose a reason for hiding this comment

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

I've been adding subclause structures whenever we had more such "bare" codeblocks (of which recent papers added a lot), but maybe itemdecls are the way to go here. In any case, I'm afraid this needs another rebase.

Copy link
Contributor

Choose a reason for hiding this comment

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

@jensmaurer would you like to take another stab at this?


\pnum
A type \tcode{I} is an \defnadj{integer-class}{type}
A type \tcode{T} is an \defnadj{integer-class}{type}
if it is in a set of \impldef{integer-class type} types
that behave as integer types do, as defined below.
\begin{note}
Expand All @@ -1354,22 +1344,22 @@
that of every integral type of the same signedness.

\pnum
A type \tcode{I} other than \cv{}~\tcode{bool} is \defn{integer-like}
if it models \tcode{\libconcept{integral}<I>} or
A type \tcode{T} other than \cv{}~\tcode{bool} is \defn{integer-like}
if it models \tcode{\libconcept{integral}<T>} or
if it is an integer-class type.
An integer-like type \tcode{I} is \defn{signed-integer-like}
if it models \tcode{\libconcept{signed_integral}<I>} or
An integer-like type \tcode{T} is \defn{signed-integer-like}
if it models \tcode{\libconcept{signed_integral}<T>} or
if it is a signed-integer-class type.
An integer-like type \tcode{I} is \defn{unsigned-integer-like}
if it models \tcode{\libconcept{unsigned_integral}<I>} or
An integer-like type \tcode{T} is \defn{unsigned-integer-like}
if it models \tcode{\libconcept{unsigned_integral}<T>} or
if it is an unsigned-integer-class type.

\pnum
For every integer-class type \tcode{I},
let \tcode{B(I)} be a unique hypothetical extended integer type
of the same signedness with the same width\iref{basic.fundamental} as \tcode{I}.
For every integer-class type \tcode{T},
let \tcode{B(T)} be a unique hypothetical extended integer type
of the same signedness with the same width\iref{basic.fundamental} as \tcode{T}.
\begin{note}
The corresponding hypothetical specialization \tcode{numeric_limits<B(I)>}
The corresponding hypothetical specialization \tcode{numeric_limits<B(T)>}
meets the requirements on \tcode{numeric_limits} specializations
for integral types\iref{numeric.limits}.
\end{note}
Expand All @@ -1389,16 +1379,16 @@
where $N$ is the width of the destination type.

\pnum
Let \tcode{a} be an object of integer-class type \tcode{I},
let \tcode{b} be an object of integer-like type \tcode{I2}
such that the expression \tcode{b} is implicitly convertible to \tcode{I},
Let \tcode{a} be an object of integer-class type \tcode{T},
let \tcode{b} be an object of integer-like type \tcode{T2}
such that the expression \tcode{b} is implicitly convertible to \tcode{T},
let \tcode{x} and \tcode{y} be, respectively,
objects of type \tcode{B(I)} and \tcode{B(I2)} as described above
objects of type \tcode{B(T)} and \tcode{B(T2)} as described above
that represent the same values as \tcode{a} and \tcode{b}, and
let \tcode{c} be an lvalue of any integral type.
\begin{itemize}
\item
The expressions \tcode{a++} and \tcode{a--} shall be prvalues of type \tcode{I}
The expressions \tcode{a++} and \tcode{a--} shall be prvalues of type \tcode{T}
whose values are equal to
that of \tcode{a} prior to the evaluation of the expressions.
The expression \tcode{a++} shall modify the value of \tcode{a}
Expand All @@ -1414,7 +1404,7 @@
is well-formed, \tcode{@a} shall also be well-formed
and have the same value, effects, and value category as \tcode{@x}.
If \tcode{@x} has type \tcode{bool}, so too does \tcode{@a};
if \tcode{@x} has type \tcode{B(I)}, then \tcode{@a} has type \tcode{I}.
if \tcode{@x} has type \tcode{B(T)}, then \tcode{@a} has type \tcode{T}.
\item
For every assignment operator \tcode{@=}
for which \tcode{c @= x} is well-formed,
Expand All @@ -1435,18 +1425,18 @@
\tcode{a @ b} and \tcode{b @ a} shall also be well-formed and
shall have the same value, effects, and value category as
\tcode{x @ y} and \tcode{y @ x}, respectively.
If \tcode{x @ y} or \tcode{y @ x} has type \tcode{B(I)},
then \tcode{a @ b} or \tcode{b @ a}, respectively, has type \tcode{I};
if \tcode{x @ y} or \tcode{y @ x} has type \tcode{B(I2)},
then \tcode{a @ b} or \tcode{b @ a}, respectively, has type \tcode{I2};
If \tcode{x @ y} or \tcode{y @ x} has type \tcode{B(T)},
then \tcode{a @ b} or \tcode{b @ a}, respectively, has type \tcode{T};
if \tcode{x @ y} or \tcode{y @ x} has type \tcode{B(T2)},
then \tcode{a @ b} or \tcode{b @ a}, respectively, has type \tcode{T2};
if \tcode{x @ y} or \tcode{y @ x} has any other type,
then \tcode{a @ b} or \tcode{b @ a}, respectively, has that type.
\end{itemize}

\pnum
An expression \tcode{E} of integer-class type \tcode{I} is
An expression \tcode{E} of integer-class type \tcode{T} is
contextually convertible to \tcode{bool}
as if by \tcode{bool(E != I(0))}.
as if by \tcode{bool(E != T(0))}.

\pnum
All integer-class types model
Expand All @@ -1457,36 +1447,47 @@
A value-initialized object of integer-class type has value 0.

\pnum
For every (possibly cv-qualified) integer-class type \tcode{I},
\tcode{numeric_limits<I>} is specialized such that
For every (possibly cv-qualified) integer-class type \tcode{T},
\tcode{numeric_limits<T>} is specialized such that
each static data member \tcode{m}
has the same value as \tcode{numeric_limits<B(I)>::m}, and
has the same value as \tcode{numeric_limits<B(T)>::m}, and
each static member function \tcode{f}
returns \tcode{I(numeric_limits<B(I)>::f())}.
returns \tcode{T(numeric_limits<B(T)>::f())}.

\pnum
For any two integer-like types \tcode{I1} and \tcode{I2},
For any two integer-like types \tcode{T1} and \tcode{T2},
at least one of which is an integer-class type,
\tcode{common_type_t<I1, I2>} denotes an integer-class type
whose width is not less than that of \tcode{I1} or \tcode{I2}.
If both \tcode{I1} and \tcode{I2} are signed-integer-like types,
then \tcode{common_type_t<I1, I2>} is also a signed-integer-like type.
\tcode{common_type_t<T1, T2>} denotes an integer-class type
whose width is not less than that of \tcode{T1} or \tcode{T2}.
If both \tcode{T1} and \tcode{T2} are signed-integer-like types,
then \tcode{common_type_t<T1, T2>} is also a signed-integer-like type.

\pnum
For any two integer-like types \tcode{I1} and \tcode{I2},
For any two integer-like types \tcode{T1} and \tcode{T2},
at least one of which is an integer-class type,
\tcode{common_type_t<I1, I2>} denotes an integer-like type
whose width is not less than that of \tcode{I1} or \tcode{I2}.
If both \tcode{I1} and \tcode{I2} are signed-integer-like types,
then \tcode{common_type_t<I1, I2>} is also a signed-integer-like type.
\tcode{common_type_t<T1, T2>} denotes an integer-like type
whose width is not less than that of \tcode{T1} or \tcode{T2}.
If both \tcode{T1} and \tcode{T2} are signed-integer-like types,
then \tcode{common_type_t<T1, T2>} is also a signed-integer-like type.

\pnum
\tcode{\exposid{is-integer-like}<I>} is \tcode{true}
if and only if \tcode{I} is an integer-like type.
\tcode{\exposid{is-signed-integer-like}<I>} is \tcode{true}
if and only if \tcode{I} is a signed-integer-like type.
\tcode{\exposid{is-integer-like}<T>} is \tcode{true}
if and only if \tcode{T} is an integer-like type.
\tcode{\exposid{is-signed-integer-like}<T>} is \tcode{true}
if and only if \tcode{T} is a signed-integer-like type.

\pnum
\begin{codeblock}
template<class I>
concept @\deflibconcept{weakly_incrementable}@ =
@\libconcept{movable}@<I> &&
requires(I i) {
typename iter_difference_t<I>;
requires @\exposid{is-signed-integer-like}@<iter_difference_t<I>>;
{ ++i } -> @\libconcept{same_as}@<I&>; // not required to be equality-preserving
i++; // not required to be equality-preserving
};
\end{codeblock}
Let \tcode{i} be an object of type \tcode{I}. When \tcode{i} is in the domain of
both pre- and post-increment, \tcode{i} is said to be \defn{incrementable}.
\tcode{I} models \tcode{\libconcept{weakly_incrementable}<I>} only if
Expand Down