Boost logo

Boost-Commit :

Subject: [Boost-commit] svn:boost r54165 - sandbox/committee/LWG/proposals
From: bdawes_at_[hidden]
Date: 2009-06-21 20:19:53

Author: bemandawes
Date: 2009-06-21 20:19:52 EDT (Sun, 21 Jun 2009)
New Revision: 54165

Initial commit
   sandbox/committee/LWG/proposals/Intentional Concept Mapping.html (contents, props changed)

Added: sandbox/committee/LWG/proposals/Intentional Concept Mapping.html
--- (empty file)
+++ sandbox/committee/LWG/proposals/Intentional Concept Mapping.html 2009-06-21 20:19:52 EDT (Sun, 21 Jun 2009)
@@ -0,0 +1,203 @@
+<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
+<meta name="ProgId" content="FrontPage.Editor.Document">
+<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
+<title>Intentional Concept Mapping</title>
+<style type="text/css">
+ ins {background-color:#A0FFA0}
+ del {background-color:#FFA0A0}
+<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111">
+ <tr>
+ <td valign="top">Document number:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
+ Date:<br>
+ 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>
+ Programming Language C++, Library Working Group<br>
+ David Abrahams &lt;dave at boostpro dot com<br>
+ Beman Dawes &lt;bdawes at acm dot org&gt;</td>
+ </tr>
+<h1>Intentional Concept Mapping</h1>
+<p>Uses of C++0x concept maps include:</p>
+ <li>Declaring the intention that a class models a concept, expressed in code
+ rather than in documentation.<br>
+ <li>Declaring to users and maintainers of the type that modeling the concept
+ is part of the type's public interface and not just happenstance; i.e. it is a
+ property that can be counted on and must be preserved as the code evolves.</li>
+<p>As of CD1, this is expressed with concept maps that are often empty:</p>
+ <pre>class Endian
+ ...
+ <pre>concept_map std::Regular&lt;Endian&gt; {}
+concept_map std::StandardLayoutType&lt;Endian&gt; {}
+concept_map std::TrivialType&lt;Endian&gt; {}</pre>
+<p>Although this formulation is technically sufficient and will ensure the type
+models the concepts, it has some problems:</p>
+ <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.<br>
+ <li>Specifying the concept maps after the class definition tends to push this
+ important activity until later in the development cycle,&nbsp; yet from a
+ design and testing standpoint it best occurs early on in the development
+ cycle.<br>
+ <li>The empty concept maps are excessively verbose.</li>
+<p>This paper proposes that the above could also be written as:</p>
+ <pre>class Endian -&gt; std::Regular, std::StandardLayoutType, std::TrivialType
+ ...
+<p>The proposed wording uses <code>-&gt;</code> as a syntax marker for the
+beginning of the list of concepts to be mapped. The authors are not wedded to
+<code>-&gt;</code> , and considered several alternate keyword and punctuation
+<p>The first keyword considered was <code>requires</code>, but it was rejected
+because when you write:</p>
+ <pre>template &lt;typename X&gt;
+&nbsp; requires&lt;EqualityComparable&lt;X&gt; &gt;
+class Y
+ ...
+<p>you're just constraining X, nothing more. &nbsp;It's pure requirement checking.
+&nbsp;When you write:</p>
+ <pre>template &lt;typename X&gt;
+class Y -&gt; EqualityComparable
+ ...
+<p>you're generating a concept map for all specializations of Y, with all that
+that implies (e.g. generation of defaults, Y&lt;T&gt; can be used where
+EqualityComparable is required, etc):</p>
+ <pre>// implied by the above
+template &lt;typename T&gt;
+concept_map EqualityComparable&lt;Y&lt;T&gt; &gt; { };</pre>
+<p>A concept_map is fundamentally different from a requires clause in other
+ways, too: the former can only occur in unconstrained contexts while the latter
+can only occur in constrained ones.</p>
+<p>We welcome syntax suggestions from the committee.</p>
+<p>The critical motivation for this proposal is the desire to be able to say &quot;my
+type models concepts XXX, YYY, and ZZZ, and is broken if it doesn't do that&quot;,
+and do that in such a way that users and maintainers understand that this is
+part of my&nbsp; type's public interface and not just happenstance.</p>
+<p>This proposal is not replacement for concept maps; we view concept maps -
+even empty ones - as meeting critical needs. We wish to make empty concept maps
+more convenient and less verbose, not replace them entirely..</p>
+<p>The motivating problem of not being able to say what we mean in the obvious
+place 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>
+<h2>Proposed Wording</h2>
+<p><i>Change 9 Classes [class] as indicated:</i></p>
+<p>A class is a type. Its name becomes a <i>class-name</i> (9.1) within its
+ <blockquote>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; identifier<br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; simple-template-id</i></p>
+ </blockquote>
+<p><i>Class-specifiers</i> and <i>elaborated-type-specifiers</i> ( are
+used to make <i>class-names</i>. An object of a class consists of a (possibly
+empty) sequence of members and base class objects.</p>
+ <blockquote>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; class-head </i><code>{</code><i> member-specification<sub>opt</sub>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; class-key identifier<sub>opt</sub> attribute-specifier<sub>opt</sub>
+<ins>mapped-concept-clause<sub>opt</sub></ins> base-clause<sub>opt</sub><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; class-key nested-name-specifier identifier
+<ins>mapped-concept-clause<sub>opt</sub></ins> base-clause<sub>opt</sub><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; class-key nested-name-specifier<sub>opt</sub>
+simple-template-id attribute-specifier<sub>opt</sub>
+<ins>mapped-concept-clause<sub>opt</sub></ins> base-clause<sub>opt</sub></i></p>
+<i>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </i><code>class</code><br>
+<i>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </i><code>struct</code><br>
+<i>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </i><code>union</code></p>
+ </blockquote>
+<p><i>After 9.9
+Nested type names [class.nested.type], add:</i></p>
+<p><b>9.10 Intentional concept mapping [class.concept.mapping]</b></p>
+ <blockquote>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </i><code>-&gt;</code><i> mapped-concept-list</i></p>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mapped-concept<code>,</code>&nbsp; mapped-concept-list<br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mapped-concept</i></p>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </i>
+<code>::</code><i><sub>opt</sub> nested-name-specifier<sub>opt</sub>
+ </blockquote>
+<p>A <i>concepts-clause</i> contains a list of concepts to map to. A concept is
+mapped to for each <i>mapped-concept</i> as if by a <code>
+concept_map</code>([]). The <code>
+concept_map</code> acts as if appears immediately after the class being defined,
+and is equivalent to:</p>
+ <blockquote>
+ <pre>concept_map <i>Concept</i>&lt;<i>Class</i>&gt; {};</pre>
+ </blockquote>
+ <p>where <i><code>Concept</code></i> is the <i>mapped-concept</i>, and <i> <code>Class</code></i>
+ is the class where the <i>mapped-concept-clause</i> appears.</p>
+ <p><i>[Example:</i></p>
+ <blockquote>
+ <pre>template &lt;typename X&gt;
+&nbsp; class Y -&gt; EqualityComparable
+&nbsp; {
+ ...
+&nbsp; };</pre>
+ <p>Generates a concept map for all specializations of Y, with all that that
+ implies (e.g. generation of defaults, Y&lt;T&gt; can be used where
+ EqualityComparable is required, etc):</p>
+ <pre>// implied by the above
+template &lt;typename T&gt;
+&nbsp; concept_map EqualityComparable&lt; Y&lt;T&gt; &gt; {};</pre>
+<p><i>--end example]</i></p>
+<p>Several people on the committee reflectors suggested features similar to this
+proposal, often with syntax using the <code>requires</code> keyword. Jerry
+Schwarz, in committee message c++std-lib-23459, suggested syntax that mimics
\ No newline at end of file

Boost-Commit list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at