[Boost-commit] svn:boost r54196 - sandbox/committee/LWG/proposals

Subject: [Boost-commit] svn:boost r54196 - sandbox/committee/LWG/proposals
From: bdawes_at_[hidden]
Date: 2009-06-22 06:21:44

Author: bemandawes
Date: 2009-06-22 06:21:43 EDT (Mon, 22 Jun 2009)
New Revision: 54196
URL: http://svn.boost.org/trac/boost/changeset/54196

Log:
Convert to N-number, fix typos, indent code blocks, remove internal comments
Text files modified: 
   sandbox/committee/LWG/proposals/Intentional |    63 +++++++++++++++++++-------------------- 
   1 files changed, 30 insertions(+), 33 deletions(-)

Modified: sandbox/committee/LWG/proposals/Intentional Concept Mapping.html
==============================================================================
--- sandbox/committee/LWG/proposals/Intentional Concept Mapping.html	(original)
+++ sandbox/committee/LWG/proposals/Intentional Concept Mapping.html	2009-06-22 06:21:43 EDT (Mon, 22 Jun 2009)
@@ -25,11 +25,11 @@
       Project:<br />
       Reply-to:</td>
 
-      <td>D2916=09-0106<br />
-      <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y-%m-%d" startspan -->2009-06-21<!--webbot bot="Timestamp" endspan i-checksum="12414" --><br />
+      <td>N2916=09-0106<br />
+      <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y-%m-%d" startspan -->2009-06-22<!--webbot bot="Timestamp" endspan i-checksum="12416" --><br />
 
       Programming Language C++, Core Working Group<br />
-      David Abrahams &lt;dave at boostpro dot com<br />
+      David Abrahams &lt;dave at boostpro dot com&gt;<br />
       Beman Dawes &lt;bdawes at acm dot org&gt;</td>
     </tr>
   </table>
@@ -54,8 +54,8 @@
   </ul>
 
   <p>As of CD1, concept maps used for this purpose are often empty:</p>
-  <pre>
-class Endian
+      <blockquote>
+  <pre>class Endian
 {
   ...
 };
@@ -65,13 +65,15 @@
 concept_map std::TrivialType&lt;Endian&gt; {}
 </pre>
 
+      </blockquote>
+
   <p>Although this formulation is technically sufficient and will ensure the
   type models the concepts, it has some problems:</p>
 
   <ul>
     <li>The location of the concept maps after the class definition subverts
     self-documentation, particularly for large classes, negating some of the
-    value as documentation to users and maintainers.</li>
+    value as documentation for users and maintainers.</li>
 
     <li>The location of the concept maps after the class definition tends to
     tends to push the important activity of constraining the class until
@@ -82,13 +84,15 @@
   </ul>
 
   <p>This paper proposes that the above code could also be written as:</p>
-  <pre>
-class Endian -&gt; std::Regular, std::StandardLayoutType, std::TrivialType
+      <blockquote>
+  <pre>class Endian -&gt; std::Regular, std::StandardLayoutType, std::TrivialType
 {
   ...
 };
 </pre>
 
+      </blockquote>
+
   <h2>Syntax</h2>
 
   <p>The proposed wording uses <code>-&gt;</code> as a syntax marker for the
@@ -101,30 +105,36 @@
   requires clause in a region of code where either could appear, but a
   <code>concept_map</code> is fundamentally different from a
   <code>requires</code> clause. When you write:</p>
-  <pre>
-template &lt;typename X&gt;
+      <blockquote>
+  <pre>template &lt;typename X&gt;
   requires&lt;EqualityComparable&lt;X&gt; &gt;
 class Y
 {
    ...
 };
-</pre>you're just constraining X, nothing more. &nbsp;It's pure requirement
+</pre>
+      </blockquote>
+      you're just constraining X, nothing more. &nbsp;It's pure requirement
 checking. &nbsp;However, when you write:
-  <pre>
-template &lt;typename X&gt;
+      <blockquote>
+  <pre>template &lt;typename X&gt;
 class Y -&gt; EqualityComparable
 {
    ...
 };
-</pre>you're generating a concept map for all specializations of
+</pre>
+      </blockquote>
+      you're generating a concept map for all specializations of
 <code>Y</code>, with all that that implies (e.g. generation of defaults,
 Y&lt;T&gt; can be used where EqualityComparable is required, etc):
-  <pre>
-// generated by the above
+      <blockquote>
+  <pre>// generated by the above
 template &lt;typename T&gt;
 concept_map EqualityComparable&lt;Y&lt;T&gt; &gt; { };
 </pre>
 
+      </blockquote>
+
   <p>We welcome syntax suggestions from the committee.</p>
 
   <h2>Motivation</h2>
@@ -143,16 +153,6 @@
   <code>concept_map</code>s will still be needed for post-hoc
   adaptation of types to concepts, an important function
   of <code>concept_map</code>s in general.</p>
-<!--
-  <p>The underlying problem of not being able to say what we mean
-  concisely&#8212;and in the obvious place&#8212;is not solved by
-  making more concepts <code>auto</code> or making <code>auto</code>
-  the default. Those are important issues, but are orthogonal to the
-  intentional concept mapping concerns of this proposal.</p>
--->
-  <!-- Beman, I'm not sure I want to bring that argument up; are you?
-  It seems a bit like inviting trouble, and I'd like to save trouble
-  for my other paper ;-) -->
 
   <h2>Proposed Wording</h2>
 
@@ -225,8 +225,7 @@
     <code>concept_map</code>([concept.map]). The <code>concept_map</code>
     acts as if appears immediately after the class being defined, and is
     equivalent to:</p>
-    <pre>
-concept_map <i>Concept</i>&lt;<i>Class</i>&gt; {};
+    <pre>concept_map <i>Concept</i>&lt;<i>Class</i>&gt; {};
 </pre>
 
     <p>where <i><code>Concept</code></i> is the <i>mapped-concept</i>, and
@@ -234,8 +233,7 @@
     <i>mapped-concept-clause</i> appears.</p>
 
     <p><i>[Example:</i></p>
-    <pre>
-template &lt;typename X&gt;
+    <pre>template &lt;typename X&gt;
   class Y -&gt; EqualityComparable
   {
      ...
@@ -243,8 +241,7 @@
 </pre>
 
     <p>The above implicitly generates the following concept map:</p>
-    <pre>
-template &lt;typename T&gt;
+    <pre>template &lt;typename T&gt;
   concept_map EqualityComparable&lt; Y&lt;T&gt; &gt; {};
 </pre>
 
@@ -258,4 +255,4 @@
   Jerry Schwarz, in committee message c++std-lib-23459, suggested syntax that
   mimics inheritance.</p>
 </body>
-</html>
+</html>
\ No newline at end of file