[Boost-commit] svn:boost r48872 - sandbox/committee/concepts/wording

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