|
Boost-Commit : |
From: dgregor_at_[hidden]
Date: 2008-04-03 15:59:35
Author: dgregor
Date: 2008-04-03 15:59:35 EDT (Thu, 03 Apr 2008)
New Revision: 44019
URL: http://svn.boost.org/trac/boost/changeset/44019
Log:
Update wording to deal with inherited constructors, and use addedConcepts in more places
Text files modified:
sandbox/committee/concepts/wording/wording.tex | 109 +++++++++++++++++++++++++++------------
1 files changed, 74 insertions(+), 35 deletions(-)
Modified: sandbox/committee/concepts/wording/wording.tex
==============================================================================
--- sandbox/committee/concepts/wording/wording.tex (original)
+++ sandbox/committee/concepts/wording/wording.tex 2008-04-03 15:59:35 EDT (Thu, 03 Apr 2008)
@@ -86,6 +86,9 @@
\item Clarified how requirements are satisfied by concept maps,
including a major cleanup of the specification of concept map lookup
(\ref{temp.req.sat}).
+\item Add text to cope with inheriting constructors
+ (\ref{class.inhctor}).
+
\end{itemize}
\section*{Typographical conventions}
@@ -1732,6 +1735,20 @@
definition has no implicit \techterm{exception-specification}.
\exitnote\
+\rSec1[class.inhctor]{Inheriting Constructors}
+\setcounter{Paras}{1}
+\pnum
+The \techterm{constructor characteristics} of a constructor or
+constructor template are
+\begin{itemize}
+\item the template parameter list (\ref{temp.param}), if any,
+\additemCC{the template requirements (\mbox{\ref{temp.req}}), if any,}
+\item the \techterm{parameter-type-list} (\ref{decl.fct}),
+\item the \techterm{exception-specification} (\ref{except.spec}),
+\item absence or presence of \tcode{explicit} (\ref{class.conv.ctor}), and
+\item absence or presence of \tcode{constexpr} (\ref{dcl.constexpr}).
+\end{itemize}
+
\setcounter{chapter}{12}
\rSec0[over]{Overloading}
@@ -2600,10 +2617,11 @@
\setcounter{subsection}{7}
\rSec2[temp.concept.map]{Concept map templates}
\pnum
-A \techterm{concept map template} defines an unbounded set of concept
+\addedConcepts{A \mbox{\techterm{concept map template}} defines an
+ unbounded set of concept
maps with a common set of associated function,
associated type, and associated template
- definitions. \enterexample\
+ definitions. \mbox{\enterexample}}
\begin{codeblock}
concept F<typename T> {
typename type;
@@ -2616,58 +2634,79 @@
T& f(T*);
}
\end{codeblock}
-\exitexample\
+\addedConcepts{\mbox{\exitexample}}
\pnum
-A concept map template is a constrained template (\ref{temp.constrained})
-\enternote\ a concept map template may be a constrained template even
-if it does not have template requirements. \exitnote\
+\addedConcepts{A concept map template is a constrained template (\mbox{\ref{temp.constrained}})
+\mbox{\enternote} a concept map template may be a constrained template even
+if it does not have template requirements. \mbox{\exitnote}}
\pnum
-Within the \techterm{template-argument-list} of the
-\techterm{concept-id} in a concept map template (including nested
+\addedConcepts{Within the \mbox{\techterm{template-argument-list}} of the
+\mbox{\techterm{concept-id}} in a concept map template (including nested
template argument lists),
-the following restrictions apply:
+the following restrictions apply:}
\begin{itemize}
\item
-A non-type argument expression shall not involve
+\addedConcepts{A non-type argument expression shall not involve
a template parameter of the concept map except when the argument
expression is a simple
-\techterm{identifier}.
+\mbox{\techterm{identifier}}.}
\item
-The type of a template parameter corresponding to a non-type argument
-shall not be dependent on a parameter of the concept map.
+\addedConcepts{The type of a template parameter corresponding to a non-type argument
+shall not be dependent on a parameter of the concept map.}
\item
-The template parameter list of a concept map template shall not contain default
+\addedConcepts{The template parameter list of a concept map template shall not contain default
template argument values.%
\footnote{
There is no way in which they could be used.
-}
+}}
\end{itemize}
\pnum
-When a particular concept map is required, concept map matching
-determines whether a
+\addedConcepts{During concept map lookup (\mbox{\ref{temp.req.sat}}),
+ concept map matching determines whether a
particular concept map template can be used. Concept map matching
matches the concept arguments in the
-\mbox{\techterm{concept
- instance}} to the
+\mbox{\techterm{concept instance}} to the
concept arguments in the concept map template, using matching of class
-template partial specializations (\ref{temp.class.spec.match}).
+template partial specializations (\mbox{\ref{temp.class.spec.match}}).}
\pnum
-If more than one concept map template matches a specific
+\addedConcepts{If more than one concept map template matches a specific
\mbox{\techterm{concept instance}}, partial ordering of concept map templates
proceeds as partial ordering of class template specializations
-(\ref{temp.class.order}).
+(\mbox{\ref{temp.class.order}}). \mbox{\enterexample}}
+\begin{codeblock}
+concept C<typename T> { }
+template<typename T> requires C<T> void f(T);
+
+template<typename T> concept_map C<T*> { /* ... */ } // \#1
+
+concept Ptr<typename T> { }
+concept_map Ptr<int*> { /* ... */ }
+
+template<typename T> requires Ptr<T> concept_map C<T> { /* ... */ } // \#2
+
+void g(int* p)
+{
+ f(g); // okay: concept map C<int*> instantiated from \#1, which is more specialized than \#2
+}
+\end{codeblock}
+\addedConcepts{\mbox{\exitexample}}
+
+\addedConcepts{When writing a template
+ constrained; keep your parameter types plain; because with a type
+ pattern, adaptation you will shatter; tho' the compiler has not even
+ complained.}
\pnum
-A concept map template shall satisfy the requirements of its corresponding
-concept (\ref{concept.map}) at the time of definition of the concept
-map template. \enterexample\
+\addedConcepts{A concept map template shall satisfy the requirements
+ of its corresponding concept (\mbox{\ref{concept.map}}) at the time of definition of the concept
+map template. \mbox{\enterexample}}
\begin{codeblock}
concept C<typename T> { }
@@ -2677,7 +2716,7 @@
template<C T> struct X;
-@\textcolor{addclr}{template}@<F T> void f(X<T>); // \#1
+template<F T> void f(X<T>); // \#1
template<typename T>
concept_map F<X<T>> { } // error: requirement for f(X<T>) not satisfied
@@ -2685,11 +2724,11 @@
@\textcolor{addclr}{}@template<F T>
concept_map F<X<T>> { } // okay: uses \#1 to satisfy requirement for f(X<T>)
\end{codeblock}
-\exitexample\
+\addedConcepts{\mbox{\exitexample}}
\pnum
-If the definition of a concept map template uses an instantiated archetype
-(\ref{temp.archetype}), and instantiation of the
+\addedConcepts{If the definition of a concept map template uses an instantiated archetype
+(\mbox{\ref{temp.archetype}}), and instantiation of the
concept map template
results in a different specialization of that class
template with an incompatible definition, the program is
@@ -2699,9 +2738,9 @@
concept map, if its definition causes any of the associated
function definitions to be ill-formed, or if the resulting concept map
fails to satisfy the axioms of the corresponding concept.
-\enterexample\
+\mbox{\enterexample}}
\begin{codeblock}
-@\textcolor{addclr}{}@concept Stack<typename X> {
+concept Stack<typename X> {
typename value_type;
value_type& top(X&);
// ...
@@ -2733,14 +2772,14 @@
// have incompatible signatures for top()
}
\end{codeblock}
-\exitexample\
+\addedConcepts{\mbox{\exitexample}}
\pnum
-A concept map template shall be declared before the first use of a
+\addedConcepts{A concept map template shall be declared before the first use of a
concept map that would make use of the concept map template
as the result of an implicit or explicit instantiation
-in every translation unit in which such a use occurs; no \textcolor{addclr}{diagnostic} is
-required.
+in every translation unit in which such a use occurs; no diagnostic is
+required.}
\color{black}
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk