Boost-Commit :

Date view	Thread view	Subject view	Author view

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

Next message: christian.schladetsch_at_[hidden]: "[Boost-commit] svn:boost r54166 - sandbox/monotonic/libs/monotonic/test"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r54164 - sandbox/committee/LWG/cd_status"

Author: bemandawes
Date: 2009-06-21 20:19:52 EDT (Sun, 21 Jun 2009)
New Revision: 54165
URL: http://svn.boost.org/trac/boost/changeset/54165

Log:
Initial commit
Added:
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 @@
+<html>
+
+<head>
+<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}
+</style>
+</head>
+
+<body>
+
+<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111">
+ <tr>
+ <td valign="top">Document number:      
+ Date: 
+ Project: 
+ Reply-to:</td>
+ <td>D2916=09-0106 
+2009-06-21 
+ Programming Language C++, Library Working Group 
+ David Abrahams <dave at boostpro dot com 
+ Beman Dawes <bdawes at acm dot org></td>
+ </tr>
+</table>
+
+<h1>Intentional Concept Mapping</h1>
+<h2>Introduction</h2>
+Uses of C++0x concept maps include:
+<ul>
+ <li>Declaring the intention that a class models a concept, expressed in code
+ rather than in documentation. 
+ </li>
+ <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>
+</ul>
+As of CD1, this is expressed with concept maps that are often empty:
+<blockquote>
+ <pre>class Endian
+{
+ ...
+};</pre>
+ <pre>concept_map std::Regular<Endian> {}
+concept_map std::StandardLayoutType<Endian> {}
+concept_map std::TrivialType<Endian> {}</pre>
+</blockquote>
+Although this formulation is technically sufficient and will ensure the type
+models the concepts, it has some problems:
+<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>
+ <li>Specifying the concept maps after the class definition tends to push this
+ important activity until later in the development cycle,  yet from a
+ design and testing standpoint it best occurs early on in the development
+ cycle. 
+ </li>
+ <li>The empty concept maps are excessively verbose.</li>
+</ul>
+This paper proposes that the above could also be written as:
+<blockquote>
+ <pre>class Endian -> std::Regular, std::StandardLayoutType, std::TrivialType
+{
+ ...
+};</pre>
+</blockquote>
+<h2>Syntax</h2>
+The proposed wording uses <code>-></code> as a syntax marker for the
+beginning of the list of concepts to be mapped. The authors are not wedded to
+<code>-></code> , and considered several alternate keyword and punctuation
+possibilities.
+The first keyword considered was <code>requires</code>, but it was rejected
+because when you write:
+<blockquote>
+ <pre>template <typename X>
+  requires<EqualityComparable<X> >
+class Y
+{
+ ...
+};</pre>
+</blockquote>
+you're just constraining X, nothing more.  It's pure requirement checking.
+ When you write:
+<blockquote>
+ <pre>template <typename X>
+class Y -> EqualityComparable
+{
+ ...
+};</pre>
+</blockquote>
+you're generating a concept map for all specializations of Y, with all that
+that implies (e.g. generation of defaults, Y<T> can be used where
+EqualityComparable is required, etc):
+<blockquote>
+ <pre>// implied by the above
+template <typename T>
+concept_map EqualityComparable<Y<T> > { };</pre>
+</blockquote>
+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.
+We welcome syntax suggestions from the committee.
+<h2>Motivation</h2>
+The critical motivation for this proposal is the desire to be able to say "my
+type models concepts XXX, YYY, and ZZZ, and is broken if it doesn't do that",
+and do that in such a way that users and maintainers understand that this is
+part of my  type's public interface and not just happenstance.
+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..
+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.
+<h2>Proposed Wording</h2>
+Change 9 Classes [class] as indicated:
+<blockquote>
+A class is a type. Its name becomes a class-name (9.1) within its
+scope.
+ <blockquote>
+class-name: 
+      identifier 
+      simple-template-id
+ </blockquote>
+Class-specifiers and elaborated-type-specifiers (7.1.6.3) are
+used to make class-names. An object of a class consists of a (possibly
+empty) sequence of members and base class objects.
+ <blockquote>
+class-specifier: 
+      class-head <code>{</code> member-specificationopt
+<code>}</code>
+class-head: 
+      class-key identifieropt attribute-specifieropt
+<ins>mapped-concept-clauseopt</ins> base-clauseopt 
+      class-key nested-name-specifier identifier
+attribute-specifieropt
+<ins>mapped-concept-clauseopt</ins> base-clauseopt 
+      class-key nested-name-specifieropt
+simple-template-id attribute-specifieropt
+<ins>mapped-concept-clauseopt</ins> base-clauseopt
+class-key: 
+      <code>class</code> 
+      <code>struct</code> 
+      <code>union</code>
+ </blockquote>
+</blockquote>
+After 9.9
+Nested type names [class.nested.type], add:
+<blockquote>
+9.10 Intentional concept mapping [class.concept.mapping]
+ <blockquote>
+mapped-concept-clause: 
+      <code>-></code> mapped-concept-list
+mapped-concept-list: 
+      mapped-concept<code>,</code>  mapped-concept-list 
+      mapped-concept
+mapped-concept: 
+      
+<code>::</code>opt nested-name-specifieropt
+concept-name
+ </blockquote>
+A concepts-clause contains a list of concepts to map to. A concept is
+mapped to for each mapped-concept as if by a <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:
+ <blockquote>
+ <pre>concept_map Concept<Class> {};</pre>
+ </blockquote>
+ where <code>Concept</code> is the mapped-concept, and <code>Class</code>
+ is the class where the mapped-concept-clause appears.
+ [Example:
+ <blockquote>
+ <pre>template <typename X>
+  class Y -> EqualityComparable
+  {
+ ...
+  };</pre>
+ Generates a concept map for all specializations of Y, with all that that
+ implies (e.g. generation of defaults, Y<T> can be used where
+ EqualityComparable is required, etc):
+ <pre>// implied by the above
+template <typename T>
+  concept_map EqualityComparable< Y<T> > {};</pre>
+</blockquote>
+--end example]
+</blockquote>
+<h2>Acknowledgements</h2>
+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
+inheritance.
+<hr>
+ 
+
+</body>
+
+</html>
\ No newline at end of file

Next message: christian.schladetsch_at_[hidden]: "[Boost-commit] svn:boost r54166 - sandbox/monotonic/libs/monotonic/test"
Previous message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r54164 - sandbox/committee/LWG/cd_status"

Date view	Thread view	Subject view	Author view

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