[Boost-commit] svn:boost r48225 - sandbox/committee/concepts/stdlib

From: dgregor_at_[hidden]
Date: 2008-08-19 14:37:32

Author: dgregor
Date: 2008-08-19 14:37:31 EDT (Tue, 19 Aug 2008)
New Revision: 48225
URL: http://svn.boost.org/trac/boost/changeset/48225

Log:
Mark all of the LWG issues that are solved by each concepts proposal
Text files modified: 
   sandbox/committee/concepts/stdlib/clib-algorithms.tex   |    16 ++++++++++++++++                        
   sandbox/committee/concepts/stdlib/clib-concepts.tex     |    16 ++++++++++++++++                        
   sandbox/committee/concepts/stdlib/clib-containers.tex   |    11 +++++++++++                             
   sandbox/committee/concepts/stdlib/clib-iterconcepts.tex |    25 +++++++++++++++++++++++++               
   sandbox/committee/concepts/stdlib/clib-numerics.tex     |    13 +++++++++++--                           
   sandbox/committee/concepts/stdlib/clib-utilities.tex    |    12 ++++++++++++                            
   6 files changed, 91 insertions(+), 2 deletions(-)

Modified: sandbox/committee/concepts/stdlib/clib-algorithms.tex
==============================================================================
--- sandbox/committee/concepts/stdlib/clib-algorithms.tex	(original)
+++ sandbox/committee/concepts/stdlib/clib-algorithms.tex	2008-08-19 14:37:31 EDT (Tue, 19 Aug 2008)
@@ -122,6 +122,22 @@
 
 \end{titlepage}
 
+\section*{Proposed Wording}
+\paragraph*{Issues resolved by concepts}
+The following LWG are resolved by concepts. These issues should be
+resolved as NAD following the application of this proposal to the
+wording paper:
+\begin{description}
+\item[Issue 631. Conflicting requirements for BinaryPredicate.]  The
+  concepts specification for \tcode{lower_bound} and
+  \tcode{upper_bound} specify an exact order for the operands,
+  following the principle that we specify minimal requirements for an
+  algorithm (within reason).
+\item[Issue 779. Resolution of \#283 incomplete.]
+The concepts proposal spells out the exact requirements for the
+\tcode{remove} algorithm.
+\end{description}
+
 %%--------------------------------------------------
 %% Headers and footers
 \pagestyle{fancy}

Modified: sandbox/committee/concepts/stdlib/clib-concepts.tex
==============================================================================
--- sandbox/committee/concepts/stdlib/clib-concepts.tex	(original)
+++ sandbox/committee/concepts/stdlib/clib-concepts.tex	2008-08-19 14:37:31 EDT (Tue, 19 Aug 2008)
@@ -136,6 +136,22 @@
 
 \end{titlepage}
 
+\section*{Proposed Wording}
+\paragraph*{Issues resolved by concepts}
+The following LWG are resolved by concepts. These issues should be
+resolved as NAD following the application of this proposal to the
+wording paper:
+\begin{description}
+\item[Issue 556. Is Compare a BinaryPredicate?] With concepts, we've
+  specified exactly what "convertible to bool" means for predicates,
+  and all Compare objects are predicates (since they refine the
+  Predicate concept). Short-circuiting is taken care of because the
+  Predicate concept forces conversion to bool inside all constrained
+  templates.
+\item[Issue 724. DefaultConstructible is not defined.]
+The concepts proposal provides a \tcode{DefaultConstructible} concept.
+\end{description}
+
 %%--------------------------------------------------
 %% Headers and footers
 \pagestyle{fancy}

Modified: sandbox/committee/concepts/stdlib/clib-containers.tex
==============================================================================
--- sandbox/committee/concepts/stdlib/clib-containers.tex	(original)
+++ sandbox/committee/concepts/stdlib/clib-containers.tex	2008-08-19 14:37:31 EDT (Tue, 19 Aug 2008)
@@ -136,6 +136,17 @@
 
 \end{titlepage}
 
+\section*{Proposed Wording}
+\paragraph*{Issues resolved by concepts}
+The following LWG are resolved by concepts. These issues should be
+resolved as NAD following the application of this proposal to the
+wording paper:
+\begin{description}
+\item[Issue 704. MoveAssignable requirement for container value type
+  overly strict.] The concepts proposal for the containers specifies
+  precisely which routines require \tcode{MoveAssignable} value types.
+\end{description}
+
 %%--------------------------------------------------
 %% Headers and footers
 \pagestyle{fancy}

Modified: sandbox/committee/concepts/stdlib/clib-iterconcepts.tex
==============================================================================
--- sandbox/committee/concepts/stdlib/clib-iterconcepts.tex	(original)
+++ sandbox/committee/concepts/stdlib/clib-iterconcepts.tex	2008-08-19 14:37:31 EDT (Tue, 19 Aug 2008)
@@ -286,6 +286,31 @@
 \end{titlepage}
 
 \section*{Proposed Wording}
+\paragraph*{Issues resolved by concepts}
+The following LWG are resolved by concepts. These issues should be
+resolved as NAD following the application of this proposal to the
+wording paper:
+\begin{description}
+\item[Issue 299. Incorrect return types for iterator dereference.]
+  Concepts specify precise return types for the iterator 
+  operations, including \tcode{operator[]}.
+\item[Issue 258. 24.1.5 contains unintented limitation for operator-.]
+  Concepts now specify that the difference type of an iterator is a
+  signed integral type.
+\item[Issue 484. Convertible to T.]
+With concepts, the iterator requirements also specify
+"convertible to T", and this conversion will automatically be used
+within constrained templates as necessary, so that the overload that
+will be selected becomes clear from the requirements of the template.
+\item[Issue 742. Enabling swap for proxy iterators.]  The concepts
+  proposal provides a two-parameter swap that is available when
+  \tcode{swap(w, v)} is valid or when the types of \tcode{w} and
+  \tcode{v} are the same and that type is \tcode{MoveAssignable} and
+  \tcode{MoveConstructible}, per the \tcode{std::swap} algorithm. The
+  use of this \tcode{HasSwap} concept in the iterator concepts and in
+  algorithms makes proxy iterators viable throughout the standard
+  library.
+\end{description}
 
 %% --------------------------------------------------
 %% Headers and footers

Modified: sandbox/committee/concepts/stdlib/clib-numerics.tex
==============================================================================
--- sandbox/committee/concepts/stdlib/clib-numerics.tex	(original)
+++ sandbox/committee/concepts/stdlib/clib-numerics.tex	2008-08-19 14:37:31 EDT (Tue, 19 Aug 2008)
@@ -58,6 +58,7 @@
 Indiana University \\
 Bloomington, IN\ \  47405 \\
 \{\href{mailto:dgregor_at_[hidden]}{dgregor}, \href{mailto:lums_at_[hidden]}{lums}\}@osl.iu.edu
+
 \end{center}
 
 \vspace{1in}
@@ -81,6 +82,14 @@
   characterizes the actual requirements for the \tcode{complex} type.
 \end{itemize}
 
+\paragraph*{Issues resolved in this paper}
+The following issue has been applied to this paper and should be resolved as NAD:
+\begin{itemize}
+\item Issue 844: complex pow return type is ambiguous. Rather than add
+  concepts to the \tcode{pow(complex, int)} function, which will be
+  removed by the proposed resolution to issue 844, we have applied the
+  proposed resolution to this document.
+\end{itemize}
 \end{titlepage}
 
 %%--------------------------------------------------
@@ -536,7 +545,7 @@
   template<@\changedConcepts{class}{FloatingPointType}@ T> complex<T> log  (const complex<T>&);
   template<@\changedConcepts{class}{FloatingPointType}@ T> complex<T> log10(const complex<T>&);
 
-  template<@\changedConcepts{class}{FloatingPointType}@ T> complex<T> pow(const complex<T>&, int);
+  @\removedConcepts{template<class T> complex<T> pow(const complex<T>\&, int);}@
   template<@\changedConcepts{class}{FloatingPointType}@ T> complex<T> pow(const complex<T>&, const T&);
   template<@\changedConcepts{class}{FloatingPointType}@ T> complex<T> pow(const complex<T>&, const complex<T>&);
   template<@\changedConcepts{class}{FloatingPointType}@ T> complex<T> pow(const T&, const complex<T>&);
@@ -1271,7 +1280,7 @@
 
 \index{pow@\tcode{pow}!\tcode{complex}}%
 \begin{itemdecl}
-template<@\changedConcepts{class}{FloatingPointType}@ T> complex<T> pow(const complex<T>& @\farg{x}@, int @\farg{y}@);
+@\removedConcepts{template<class T> complex<T> pow(const complex<T>\& \mbox{\farg{x}}, int \mbox{\farg{y}});}@
 template<@\changedConcepts{class}{FloatingPointType}@ T> complex<T> pow(const complex<T>& @\farg{x}@, const complex<T>& @\farg{y}@);
 template<@\changedConcepts{class}{FloatingPointType}@ T> complex<T> pow(const complex<T>& @\farg{x}@, const T& @\farg{y}@);
 template<@\changedConcepts{class}{FloatingPointType}@ T> complex<T> pow  (const T& @\farg{x}@, const complex<T>& @\farg{y}@);

Modified: sandbox/committee/concepts/stdlib/clib-utilities.tex
==============================================================================
--- sandbox/committee/concepts/stdlib/clib-utilities.tex	(original)
+++ sandbox/committee/concepts/stdlib/clib-utilities.tex	2008-08-19 14:37:31 EDT (Tue, 19 Aug 2008)
@@ -80,6 +80,18 @@
 
 \end{titlepage}
 
+\section*{Proposed Wording}
+\paragraph*{Issues resolved by concepts}
+The following LWG are resolved by concepts. These issues should be
+resolved as NAD following the application of this proposal to the
+wording paper:
+\begin{description}
+\item[Issue 811. Pair of pointers no longer works with literal 0.]  As
+  mentioned in the discussion of the issue, making \tcode{pair} a
+  constrained templates solves the problem of construction from a
+  literal 0.
+\end{description}
+
 %%--------------------------------------------------
 %% Headers and footers
 \pagestyle{fancy}