Skip to content

Library-wide: Use "model" instead of "satisfy" with library concept r… #2797

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

Merged
merged 3 commits into from
Jun 14, 2019
Merged
Show file tree
Hide file tree
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
66 changes: 37 additions & 29 deletions source/concepts.tex
Original file line number Diff line number Diff line change
Expand Up @@ -134,8 +134,9 @@
};
\end{codeblock}

\tcode{T} fails to meet the implicit requirements of \tcode{C}, so \tcode{C<T>}
is not satisfied. Since implementations are not required to validate the syntax
\tcode{T} fails to meet the implicit requirements of \tcode{C},
so \tcode{T} satisfies but does not model \tcode{C}.
Since implementations are not required to validate the syntax
of implicit requirements, it is unspecified whether an implementation diagnoses
as ill-formed a program that requires \tcode{C<T>}.
\end{example}
Expand Down Expand Up @@ -332,9 +333,11 @@
return f();
}
\end{codeblock}
for some types \tcode{From} and \tcode{To},
and let \tcode{f} be a function with no arguments and return type \tcode{From}
such that \tcode{f()} is equality-preserving.
\tcode{\libconcept{ConvertibleTo}<From, To>} is satisfied only if:
\tcode{From} and \tcode{To} model \tcode{\libconcept{ConvertibleTo}<From, To>}
only if:

\begin{itemize}
\item
Expand Down Expand Up @@ -366,7 +369,7 @@
\tcode{\libconcept{ConvertibleTo}<T, C>}
and
\tcode{\libconcept{ConvertibleTo}<U, C>}
are satisfied, then \tcode{T} and \tcode{U} share a
are modeled, then \tcode{T} and \tcode{U} share a
\term{common reference type}, \tcode{C}.
\begin{note}
\tcode{C} could be the same as \tcode{T}, or \tcode{U}, or it could be a
Expand Down Expand Up @@ -478,13 +481,13 @@
\begin{itemdescr}
\pnum
\begin{note}
\tcode{\libconcept{SignedIntegral}<T>} can be satisfied even by types that are
\libconcept{SignedIntegral} can be modeled even by types that are
not signed integral types\iref{basic.fundamental}; for example, \tcode{char}.
\end{note}

\pnum
\begin{note}
\tcode{\libconcept{UnsignedIntegral}<T>} can be satisfied even by types that are
\libconcept{UnsignedIntegral} can be modeled even by types that are
not unsigned integral types\iref{basic.fundamental}; for example, \tcode{bool}.
\end{note}
\end{itemdescr}
Expand Down Expand Up @@ -512,7 +515,8 @@
\tcode{RHS}, and
\item \tcode{rcopy} be a distinct object that is equal to \tcode{rhs}.
\end{itemize}
\tcode{\libconcept{Assignable}<LHS, RHS>} is satisfied only if
\tcode{LHS} and \tcode{RHS} model
\tcode{\libconcept{Assignable}<LHS, RHS>} only if

\begin{itemize}
\item \tcode{addressof(lhs = rhs) == addressof(lcopy)}.
Expand Down Expand Up @@ -760,7 +764,7 @@
\pnum
If \tcode{T} is an object type, then let \tcode{rv} be an rvalue of type
\tcode{T} and \tcode{u2} a distinct object of type \tcode{T} equal to
\tcode{rv}. \tcode{\libconcept{MoveConstructible}<T>} is satisfied only if
\tcode{rv}. \tcode{T} models \libconcept{MoveConstructible} only if

\begin{itemize}
\item After the definition \tcode{T u = rv;}, \tcode{u} is equal to \tcode{u2}.
Expand Down Expand Up @@ -788,7 +792,7 @@
\pnum
If \tcode{T} is an object type, then let \tcode{v} be an lvalue of type
(possibly \tcode{const}) \tcode{T} or an rvalue of type \tcode{const T}.
\tcode{\libconcept{CopyConstructible}<T>} is satisfied only if
\tcode{T} models \libconcept{CopyConstructible} only if

\begin{itemize}
\item After the definition \tcode{T u = v;}, \tcode{u} is equal to \tcode{v}.
Expand Down Expand Up @@ -837,9 +841,9 @@
\end{itemdecl}

\pnum
Let \tcode{b1} and \tcode{b2} be lvalues of type
\tcode{const remove_reference_t<B>}.
\tcode{\libconcept{Boolean}<B>} is satisfied only if
For some type \tcode{B}, let \tcode{b1} and \tcode{b2} be
lvalues of type \tcode{const remove_reference_t<B>}.
\tcode{B} models \libconcept{Boolean} only if

\begin{itemize}
\item \tcode{bool(b1) == !bool(!b1)}.
Expand Down Expand Up @@ -883,11 +887,12 @@

\begin{itemdescr}
\pnum
Let \tcode{t} and \tcode{u} be lvalues of types
For some types \tcode{T} and \tcode{U},
let \tcode{t} and \tcode{u} be lvalues of types
\tcode{const remove_reference_t<T>} and
\tcode{const remove_reference_t<U>} respectively.
\tcode{\placeholder{weakly-equality-comparable-with}<T, U>}
is satisfied only if:
\tcode{T} and \tcode{U} model
\tcode{\placeholder{weakly-equality-comparable-with}<T, U>} only if
\begin{itemize}
\item \tcode{t == u}, \tcode{u == t}, \tcode{t != u}, and \tcode{u != t}
have the same domain.
Expand All @@ -906,7 +911,7 @@
\begin{itemdescr}
\pnum
Let \tcode{a} and \tcode{b} be objects of type \tcode{T}.
\tcode{\libconcept{EqualityComparable}<T>} is satisfied only if
\tcode{T} models \libconcept{EqualityComparable} only if
\tcode{bool(a == b)} is \tcode{true} when \tcode{a} is equal to
\tcode{b}\iref{concepts.equality}, and \tcode{false} otherwise.

Expand All @@ -932,13 +937,15 @@

\begin{itemdescr}
\pnum
Let \tcode{t} be an lvalue of type \tcode{const remove_reference_t<T>},
For some types \tcode{T} and \tcode{U},
let \tcode{t} be an lvalue of type \tcode{const remove_reference_t<T>},
\tcode{u} be an lvalue of type \tcode{const remove_reference_t<U>},
and \tcode{C} be:
\begin{codeblock}
common_reference_t<const remove_reference_t<T>&, const remove_reference_t<U>&>
\end{codeblock}
\tcode{\libconcept{EqualityComparableWith}<T, U>} is satisfied only if
\tcode{T} and \tcode{U} model
\tcode{\libconcept{EqualityComparableWith}<T, U>} only if
\tcode{bool(t == u) == bool(C(t) == C(u))}.
\end{itemdescr}

Expand All @@ -960,9 +967,9 @@

\begin{itemdescr}
\pnum
Let \tcode{a}, \tcode{b}, and \tcode{c} be lvalues of type
\tcode{const remove_reference_t<T>}.
\tcode{\libconcept{StrictTotallyOrdered}<T>} is satisfied only if
For some type \tcode{T}, let \tcode{a}, \tcode{b}, and \tcode{c} be
lvalues of type \tcode{const remove_reference_t<T>}.
\tcode{T} models \libconcept{StrictTotallyOrdered} only if

\begin{itemize}
\item Exactly one of \tcode{bool(a < b)}, \tcode{bool(a > b)}, or
Expand Down Expand Up @@ -1001,13 +1008,15 @@

\begin{itemdescr}
\pnum
Let \tcode{t} be an lvalue of type \tcode{const remove_reference_t<T>},
For some types \tcode{T} and \tcode{U},
let \tcode{t} be an lvalue of type \tcode{const remove_reference_t<T>},
\tcode{u} be an lvalue of type \tcode{const remove_reference_t<U>},
and \tcode{C} be:
\begin{codeblock}
common_reference_t<const remove_reference_t<T>&, const remove_reference_t<U>&>
\end{codeblock}
\tcode{\libconcept{StrictTotallyOrderedWith}<T, U>} is satisfied only if
\tcode{T} and \tcode{U} model
\tcode{\libconcept{StrictTotallyOrderedWith}<T, U>} only if

\begin{itemize}
\item \tcode{bool(t < u) == bool(C(t) < C(u)).}
Expand Down Expand Up @@ -1045,14 +1054,14 @@
\begin{itemdescr}
\pnum
\begin{note}
The \libconcept{Semiregular} concept is satisfied by types that behave similarly
The \libconcept{Semiregular} concept is modeled by types that behave similarly
to built-in types like \tcode{int}, except that they might not
be comparable with \tcode{==}.
\end{note}

\pnum
\begin{note}
The \libconcept{Regular} concept is satisfied by types that behave similarly to
The \libconcept{Regular} concept is modeled by types that behave similarly to
built-in types like \tcode{int} and that are comparable with
\tcode{==}.
\end{note}
Expand Down Expand Up @@ -1084,7 +1093,7 @@
\begin{itemdescr}
\pnum
\begin{example}
A function that generates random numbers can satisfy \libconcept{Invocable},
A function that generates random numbers can model \libconcept{Invocable},
since the \tcode{invoke} function call expression is not required to be
equality-preserving\iref{concepts.equality}.
\end{example}
Expand All @@ -1110,8 +1119,7 @@

\pnum
\begin{example}
A random number generator does not satisfy
\libconcept{RegularInvocable}.
A random number generator does not model \libconcept{RegularInvocable}.
\end{example}

\pnum
Expand Down Expand Up @@ -1149,7 +1157,7 @@

\begin{itemdescr}
\pnum
A \libconcept{Relation} satisfies \libconcept{StrictWeakOrder} only if
A \libconcept{Relation} models \libconcept{StrictWeakOrder} only if
it imposes a \term{strict weak ordering} on its arguments.

\pnum
Expand Down
12 changes: 6 additions & 6 deletions source/lib-intro.tex
Original file line number Diff line number Diff line change
Expand Up @@ -478,7 +478,7 @@
\item Template arguments
\item Derived classes
\item Containers, iterators, and algorithms that meet an interface convention or
satisfy a concept
model a concept
\end{itemize}

\pnum
Expand Down Expand Up @@ -533,7 +533,7 @@
concept\iref{concept.stricttotallyordered} does not meet the
semantic requirements of that concept when operating on NaNs.
\end{example}
This does not affect whether a type satisfies the concept.
This does not affect whether a type models the concept.

\pnum
A declaration may explicitly impose requirements through its associated
Expand Down Expand Up @@ -993,23 +993,23 @@
enforcing semantic requirements on that interaction.

\pnum
The type of a customization point object shall satisfy
The type of a customization point object shall model
\libconcept{Semiregular}\iref{concepts.object}.

\pnum
All instances of a specific customization point object type shall
be equal\iref{concepts.equality}.

\pnum
The type \tcode{T} of a customization point object shall satisfy
The type \tcode{T} of a customization point object shall model
\tcode{\libconcept{Invocable}<const T\&, Args...>}\iref{concept.invocable}
when the types in \tcode{Args...} meet the requirements specified in that
customization point object's definition. When the types of \tcode{Args...} do
not meet the customization point object's requirements, \tcode{T} shall not have
a function call operator that participates in overload resolution.

\pnum
Each customization point object type constrains its return type to satisfy a
Each customization point object type constrains its return type to model a
particular concept.

\pnum
Expand Down Expand Up @@ -2988,7 +2988,7 @@
\rSec3[res.on.requirements]{Semantic requirements}
\pnum
If the semantic requirements of a declaration's
constraints\iref{structure.requirements} are not satisfied at the point of use,
constraints\iref{structure.requirements} are not modeled at the point of use,
the program is ill-formed, no diagnostic required.

\rSec2[conforming]{Conforming implementations}
Expand Down
4 changes: 2 additions & 2 deletions source/ranges.tex
Original file line number Diff line number Diff line change
Expand Up @@ -2359,7 +2359,7 @@
\end{codeblock}

\item If \tcode{\libconcept{Assignable}<T\&, const T\&>} is not
satisfied, the copy assignment operator is equivalent to:
modeled, the copy assignment operator is equivalent to:
\begin{codeblock}
@\placeholder{semiregular}@& operator=(const @\placeholder{semiregular}@& that)
noexcept(is_nothrow_copy_constructible_v<T>)
Expand All @@ -2370,7 +2370,7 @@
}
\end{codeblock}

\item If \tcode{\libconcept{Assignable}<T\&, T>} is not satisfied,
\item If \tcode{\libconcept{Assignable}<T\&, T>} is not modeled,
the move assignment operator is equivalent to:
\begin{codeblock}
@\placeholder{semiregular}@& operator=(@\placeholder{semiregular}@&& that)
Expand Down