Subject: [Boost-commit] svn:boost r48872 - sandbox/committee/concepts/wording
From: dgregor_at_[hidden]
Date: 2008-09-19 02:43:46
Author: dgregor
Date: 2008-09-19 02:43:44 EDT (Fri, 19 Sep 2008)
New Revision: 48872
URL: http://svn.boost.org/trac/boost/changeset/48872
Log:
Refactor archetype construction into its own section
Text files modified:
sandbox/committee/concepts/wording/wording.tex | 362 +++++++++++++++++----------------------
1 files changed, 161 insertions(+), 201 deletions(-)
Modified: sandbox/committee/concepts/wording/wording.tex
==============================================================================
--- sandbox/committee/concepts/wording/wording.tex (original)
+++ sandbox/committee/concepts/wording/wording.tex 2008-09-19 02:43:44 EDT (Fri, 19 Sep 2008)
@@ -80,30 +80,7 @@
%
This document
provides wording for changes to the core language. Changes to the
-standard library are discussed in separate documents:
-
-\begin{itemize}
-\item N2618=08-0128: Concepts for the C++0x Standard Library: Introduction (Revision 1)
-\item N2619=08-0129: Concepts for the \Cpp{}0x Standard Library:
- Language Support Library
-\item N2620=08-0130: Concepts for the C++0x Standard Library:
- Diagnostics library
-\item N2737=08-0247: Foundational Concepts for the C++0x Standard Library
- (Revision 3)
-\item N2735=08-0245: Concepts for the C++0x Standard Library:
- Utilities (Revision 3)
-\item N2738=08-0248: Concepts for the C++0x Standard Library:
- Containers (Revision 2)
-\item N2739=08-0249: Iterator Concepts for the C++0x Standard Library
- (Revision 3)
-\item N2734=08-0244: Concepts for the C++0x Standard Library:
- Iterators (Revision 3)
-\item N2740=08-0250: Concepts for the C++0x Standard Library:
- Algorithms (Revision 3)
-\item N2736=08-0246: Concepts for the C++0x Standard Library: Numerics
- (Revision 2)
-\item N2654=08-0161: Allocator Concepts (Revision 1)
-\end{itemize}
+standard library are discussed in separate documents.
\section*{Changes from N2741}
\begin{itemize}
@@ -119,6 +96,7 @@
\item Replaced the term \techterm{late-check-block} with \techterm{late-checked-block}.
\item Removed the compiler-supported concept \tcode{std::FunctionType}, because it was found to be unnecessary as a compile built-in.
\item Introduced the model of archetypes as class types, and adjusted certain other types (e.g., ``object type'') to allow for archetypes that are meant to stand in for those types. For example, \tcode{T} where the requirement \tcode{std::ObjectType<T>} is in scope.
+\item Move the text describing how to build an archetype from concept requirements into its own section (\ref{temp.archetype.assemble}).
\end{itemize}
\section*{Typographical conventions}
@@ -2528,7 +2506,7 @@
\index{static@\tcode{static}!overloading~and}%
Member function declarations with the same name\changedConcepts{ and}{,} the same
\techterm{parameter-type-list}\addedConcepts{ and the same template requirements (if
- any)}, the same cannot be overloaded if any of them is a
+ any)}\removedConcepts{,} cannot be overloaded if any of them is a
\tcode{static}
member function declaration (\ref{class.static}).
Likewise, member function template declarations with the same name,
@@ -2835,16 +2813,7 @@
@\textit{T}@& operator*(@\textit{T}@*);
\end{codeblock}
-\pnum
-For every
-\addedCC{effective}
-function type
-\textit{T},
-there exist candidate operator functions of the form
-
-\begin{codeblock}
-@\textit{T}@& operator*(@\textit{T}@*);
-\end{codeblock}
+\setcounter{Paras}{6}
\pnum
For every type
@@ -5833,7 +5802,6 @@
concept ReferentType<typename T> { }
concept VariableType<typename T> { }
concept ObjectType<typename T> @\textit{see below}@;
- concept FunctionType<typename T> @\textit{see below}@;
concept ValueType<typename T> @\textit{see below}@;
concept ClassType<typename T> @\textit{see below}@;
concept Class<typename T> @\textit{see below}@;
@@ -5962,18 +5930,6 @@
\end{itemdescr}
\begin{itemdecl}
-concept FunctionType<typename T> : MemberPointeeType<T> { }
-\end{itemdecl}
-
-\begin{itemdescr}
-\pnum
-\addedConcepts{\mbox{\reallynote} describes function types (\mbox{\ref{dcl.fct}}).}
-
-\pnum
-\addedConcepts{\mbox{\requires} for every type \mbox{\tcode{T}} that is a function type, a concept map \mbox{\tcode{FunctionType<T>}} is implicitly defined in namespace \mbox{\tcode{std}}.}
-\end{itemdescr}
-
-\begin{itemdecl}
concept ValueType<typename T> : ObjectType<T>, VariableType<T>, MemberPointeeType<T> { }
\end{itemdecl}
@@ -6986,6 +6942,163 @@
\color{addclr}
\pnum
+\addedCC{
+ An archetype \mbox{\tcode{T}} is said to be \mbox{\techterm{from}} a given concept instance if \mbox{\tcode{T}}
+ appears in the template argument list of the concept instance when that
+ concept instance appears in a requirement whose potential scope
+ encloses a region where the archetype \mbox{\tcode{T}} is used.
+ \enterexample}
+ \begin{codeblock}
+ concept C<typename T> {}
+ template <C T> void f( T ) {}
+ \end{codeblock} \addedCC{ Beginning at the declaration of \mbox{\tcode{T}} until the
+ closing curly brace of the definition of \mbox{\tcode{f(T)}} above, we say that \mbox{\tcode{T}} ``is
+ from \mbox{\tcode{C<T>}}''. \exitexample
+}
+
+\pnum
+\addedCC{Archetypes are synthesized from the template requirements of the constrained template in which it is defined; see~\mbox{\ref{temp.archetype.assemble}}.}
+
+\pnum
+\addedConcepts{If two associated member function or member function template
+requirements that name a constructor or destructor for a type
+\mbox{\tcode{T}} have the same signature, the duplicate signature is ignored.}
+
+\pnum
+\addedConcepts{If a class template specialization is
+an archetype that does not appear as a template argument of any
+explicitly-specified requirement in the template requirements and
+whose template is not itself an archetype, then the archetype is an
+instantiated archetype. An \mbox{\techterm{instantiated archetype}} is
+an archetype whose definition is provided by the instantiation of its
+template with its template arguments (which involve archetypes).
+The template shall not be an unconstrained
+template. \mbox{\enternote} Partial ordering of class
+template partial specializations (\mbox{\ref{temp.class.order}}) depends
+on the properties of the archetypes, as defined by the requirements
+of the constrained template. When the constrained template is
+instantiated (\mbox{\ref{temp.constrained.inst}}), partial ordering of class
+template partial specializations occurs a second time based on the
+actual template arguments. \mbox{\exitnote} \mbox{\enterexample}}
+\begin{codeblock}
+template<EqualityComparable T>
+struct simple_multiset {
+ bool includes(const T&);
+ void insert(const T&);
+ // ...
+};
+
+template<LessThanComparable T>
+struct simple_multiset<T> { // A
+ bool includes(const T&);
+ void insert(const T&);
+ // ...
+};
+
+template<LessThanComparable T>
+bool first_access(const T& x) {
+ static simple_multiset<T> set; // instantiates \tcode{simple_multiset<T$'$>}, where \tcode{T$'$} is the archetype of \tcode{T} ,
+ // from the partial specialization of simple_multiset marked 'A'
+ return set.includes(x)? false : (set.insert(x), true);
+}
+\end{codeblock}
+\addedConcepts{\mbox{\exitexample}}
+
+\addedConcepts{\mbox{\enternote} Class template specializations for which
+ template requirements are specified behave as normal
+ archetypes. \mbox{\exitnote} \mbox{\enterexample}}
+\begin{codeblock}
+auto concept CopyConstructible<typename T> {
+ T::T(const T&);
+}
+
+template<CopyConstructible T> struct vector;
+
+auto concept VectorLike<typename X> {
+ typename value_type = typename X::value_type;
+ X::X();
+ void X::push_back(const value_type&);
+ value_type& X::front();
+}
+
+template<CopyConstructible T>
+requires VectorLike<vector<T>> // vector<T> is an archetype (but not an instantiated archetype)
+void f(const T& value) {
+ vector<T> x; // okay: default constructor in VectorLike<vector<T> >
+ x.push_back(value); // okay: push_back in VectorLike<vector<T> >
+ VectorLike<vector<T>>::value_type& val = x.front(); // okay: front in VectorLike<vector<T>>
+}
+\end{codeblock}
+\addedConcepts{\mbox{\exitexample}}
+
+\pnum
+\addedConcepts{\mbox{\enternote} Constrained class templates involving
+ recursive definitions are ill-formed if the recursive class template
+ specialization is an instantiated archetype. Constrained class
+ templates involving recursive definitions can be specified by
+ adding template requirements on the recursive class template
+ specializations, making them archetypes that are not instantiated
+ archetypes. \mbox{\enterexample}}
+\begin{codeblock}
+template<CopyConstructible... T> class tuple;
+
+template<CopyConstructible Head, CopyConstructible... Tail>
+class tuple<Head, Tail...> : tuple<Tail...> // ill-formed: tuple<Tail...> is an instantiated archetype,
+ // but it is an incomplete type
+{
+ Head head;
+ // ...
+};
+
+template<> class tuple<> { /* ... */ };
+
+\end{codeblock}
+\addedConcepts{\mbox{\exitexample\exitnote}}
+
+\pnum
+\addedConcepts{In a constrained context, for each concept requirement
+that is stated in or implied by the corresponding requirements,
+a \mbox{\techterm{concept map archetype}} for that
+requirement is synthesized by
+substituting the archetype of \mbox{\tcode{T}} for each occurrence of
+\mbox{\tcode{T}} within the template arguments of the requirement. The
+concept map archetype acts as a concept
+map, and its definition is used to resolve name
+lookup into
+requirements scope (\mbox{\ref{basic.scope.req}}) and satisfy the
+requirements of templates used inside the constrained context.
+When the definition of a concept map archetype is required,
+ it is synthesized from the definition of its corresponding
+ concept (\mbox{\ref{concept.map}}). An implementation shall not
+ define a concept map archetype
+ unless the definition of that concept map archetype is required.}
+%
+\addedConcepts{\mbox{\enterexample}}
+\begin{codeblock}
+concept SignedIntegral<typename T> {
+ T::T(const T&);
+ T operator-(T);
+}
+concept RandomAccessIterator<typename T> {
+ SignedIntegral difference_type;
+ difference_type operator-(T, T);
+}
+template<SignedIntegral T> T negate(const T& t) { return -t; }
+
+template<RandomAccessIterator Iter>
+RandomAccessIterator<Iter>::difference_type distance(Iter f, Iter l) {
+ typedef RandomAccessIterator<Iter>::difference_type D;
+ D dist = f - l; // okay: - operator resolves to synthesized operator- in
+ // the concept map archetype RandomAccessIterator<Iter$'$>,
+ // where Iter$'$ is the archetype of Iter
+ return negate(dist); // okay, concept map archetype RandomAccessIterator<Iter$'$>
+ // implies the concept map archetype SignedIntegral<D$'$>,
+ // where D$'$ is the archetype of D}
+\end{codeblock}
+\addedConcepts{\mbox{\exitexample}}
+
+\rSec3[temp.archetype.assemble]{Assembling archetypes}
+\pnum
\removedCCC{An archetype \mbox{\tcode{T$'$}} for a type
\mbox{\tcode{T}}} \addedCC{is all of the following that apply:}
\begin{itemize}
@@ -7037,21 +7150,6 @@
}
\pnum
-\addedCC{
- An archetype T is said to be \emph{from} a given concept instance if T
- appears in the template argument list of the concept instance when that
- concept instance appears in a requirement whose potential scope
- encloses a region where the archetype T is used.
- \enterexample}
- \begin{codeblock}
- concept C<typename T> {}
- template <C T> void f( T ) {}
- \end{codeblock} \addedCC{ Beginning at the declaration of T until the
- closing curly brace of the definition of f(T) above, we say that T ``is
- from C<T>''. \exitexample
-}
-
-\pnum
\addedConcepts{The archetype \mbox{\tcode{T$'$}} of \mbox{\tcode{T}} contains a public member
function or member function template
corresponding to each member function or member function template of
@@ -7164,144 +7262,6 @@
within the template requirements, the repeated \mbox{\tcode{std::DerivedFrom<T,
Base>}} requirements are ignored.}
-\pnum
-\addedConcepts{If two associated member function or member function template
-requirements that name a constructor or destructor for a type
-\mbox{\tcode{T}} have the same signature, the duplicate signature is ignored.}
-
-\pnum
-\addedConcepts{If a class template specialization is
-an archetype that does not appear as a template argument of any
-explicitly-specified requirement in the template requirements and
-whose template is not itself an archetype, then the archetype is an
-instantiated archetype. An \mbox{\techterm{instantiated archetype}} is
-an archetype whose definition is provided by the instantiation of its
-template with its template arguments (which involve archetypes).
-The template shall not be an unconstrained
-template. \mbox{\enternote} Partial ordering of class
-template partial specializations (\mbox{\ref{temp.class.order}}) depends
-on the properties of the archetypes, as defined by the requirements
-of the constrained template. When the constrained template is
-instantiated (\mbox{\ref{temp.constrained.inst}}), partial ordering of class
-template partial specializations occurs a second time based on the
-actual template arguments. \mbox{\exitnote} \mbox{\enterexample}}
-\begin{codeblock}
-template<EqualityComparable T>
-struct simple_multiset {
- bool includes(const T&);
- void insert(const T&);
- // ...
-};
-
-template<LessThanComparable T>
-struct simple_multiset<T> { // A
- bool includes(const T&);
- void insert(const T&);
- // ...
-};
-
-template<LessThanComparable T>
-bool first_access(const T& x) {
- static simple_multiset<T> set; // instantiates \tcode{simple_multiset<T$'$>}, where \tcode{T$'$} is the archetype of \tcode{T} ,
- // from the partial specialization of simple_multiset marked 'A'
- return set.includes(x)? false : (set.insert(x), true);
-}
-\end{codeblock}
-\addedConcepts{\mbox{\exitexample}}
-
-\addedConcepts{\mbox{\enternote} Class template specializations for which
- template requirements are specified behave as normal
- archetypes. \mbox{\exitnote} \mbox{\enterexample}}
-\begin{codeblock}
-auto concept CopyConstructible<typename T> {
- T::T(const T&);
-}
-
-template<CopyConstructible T> struct vector;
-
-auto concept VectorLike<typename X> {
- typename value_type = typename X::value_type;
- X::X();
- void X::push_back(const value_type&);
- value_type& X::front();
-}
-
-template<CopyConstructible T>
-requires VectorLike<vector<T>> // vector<T> is an archetype (but not an instantiated archetype)
-void f(const T& value) {
- vector<T> x; // okay: default constructor in VectorLike<vector<T> >
- x.push_back(value); // okay: push_back in VectorLike<vector<T> >
- VectorLike<vector<T>>::value_type& val = x.front(); // okay: front in VectorLike<vector<T>>
-}
-\end{codeblock}
-\addedConcepts{\mbox{\exitexample}}
-
-\pnum
-\addedConcepts{\mbox{\enternote} Constrained class templates involving
- recursive definitions are ill-formed if the recursive class template
- specialization is an instantiated archetype. Constrained class
- templates involving recursive definitions can be specified by
- adding template requirements on the recursive class template
- specializations, making them archetypes that are not instantiated
- archetypes. \mbox{\enterexample}}
-\begin{codeblock}
-template<CopyConstructible... T> class tuple;
-
-template<CopyConstructible Head, CopyConstructible... Tail>
-class tuple<Head, Tail...> : tuple<Tail...> // ill-formed: tuple<Tail...> is an instantiated archetype,
- // but it is an incomplete type
-{
- Head head;
- // ...
-};
-
-template<> class tuple<> { /* ... */ };
-
-\end{codeblock}
-\addedConcepts{\mbox{\exitexample\exitnote}}
-
-\pnum
-\addedConcepts{In a constrained context, for each concept requirement
-that is stated in or implied by the corresponding requirements,
-a \mbox{\techterm{concept map archetype}} for that
-requirement is synthesized by
-substituting the archetype of \mbox{\tcode{T}} for each occurrence of
-\mbox{\tcode{T}} within the template arguments of the requirement. The
-concept map archetype acts as a concept
-map, and its definition is used to resolve name
-lookup into
-requirements scope (\mbox{\ref{basic.scope.req}}) and satisfy the
-requirements of templates used inside the constrained context.
-When the definition of a concept map archetype is required,
- it is synthesized from the definition of its corresponding
- concept (\mbox{\ref{concept.map}}). An implementation shall not
- define a concept map archetype
- unless the definition of that concept map archetype is required.}
-%
-\addedConcepts{\mbox{\enterexample}}
-\begin{codeblock}
-concept SignedIntegral<typename T> {
- T::T(const T&);
- T operator-(T);
-}
-concept RandomAccessIterator<typename T> {
- SignedIntegral difference_type;
- difference_type operator-(T, T);
-}
-template<SignedIntegral T> T negate(const T& t) { return -t; }
-
-template<RandomAccessIterator Iter>
-RandomAccessIterator<Iter>::difference_type distance(Iter f, Iter l) {
- typedef RandomAccessIterator<Iter>::difference_type D;
- D dist = f - l; // okay: - operator resolves to synthesized operator- in
- // the concept map archetype RandomAccessIterator<Iter$'$>,
- // where Iter$'$ is the archetype of Iter
- return negate(dist); // okay, concept map archetype RandomAccessIterator<Iter$'$>
- // implies the concept map archetype SignedIntegral<D$'$>,
- // where D$'$ is the archetype of D}
-\end{codeblock}
-\addedConcepts{\mbox{\exitexample}}
-
\rSec2[temp.constrained.set]{Candidate sets}
\pnum
\addedConcepts{A \mbox{\techterm{candidate set}} is a set containing