Boost-Commit :

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r54168 - sandbox/committee/LWG/proposals
From: dave_at_[hidden]
Date: 2009-06-21 22:33:40

Next message: dave_at_[hidden]: "[Boost-commit] svn:boost r54169 - sandbox/committee/LWG/proposals"
Previous message: christian.schladetsch_at_[hidden]: "[Boost-commit] svn:boost r54167 - in sandbox/monotonic/libs/monotonic/test: . results"

Author: dave
Date: 2009-06-21 22:33:39 EDT (Sun, 21 Jun 2009)
New Revision: 54168
URL: http://svn.boost.org/trac/boost/changeset/54168

Log:
Tidied. Sorry, but I couldn't read it to edit it and I don't have any
WYSIWYG text editor that imports it in such a way that I can work with
it. Feel free to un-tidy again if you wish.

Text files modified:
sandbox/committee/LWG/proposals/Intentional | 435 +++++++++++++++++++++++----------------
1 files changed, 259 insertions(+), 176 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-21 22:33:39 EDT (Sun, 21 Jun 2009)
@@ -1,203 +1,286 @@
-<html>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

+<html xmlns="http://www.w3.org/1999/xhtml">
<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">
+ <meta name="GENERATOR" content="Microsoft FrontPage 5.0" />
+ <meta name="ProgId" content="FrontPage.Editor.Document" />
+ <meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
+
+ <title>Intentional Concept Mapping</title>
+ <style type="text/css">
+/*<![CDATA[*/
 ins {background-color:#A0FFA0}
 del {background-color:#FFA0A0}
-</style>
+ /*]]>*/
+ </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:

-<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
+ <blockquote>
+ <pre>
+class Endian
{
 ...
-};</pre>
- <pre>concept_map std::Regular<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
+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> >
+};
+</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>
+};
+</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
+};
+</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:
+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>
- <pre>concept_map Concept<Class> {};</pre>
+ 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>
- where <code>Concept</code> is the mapped-concept, and <code>Class</code>
- is the class where the mapped-concept-clause appears.
- [Example:
+
+ After 9.9 Nested type names [class.nested.type], add:
+
 <blockquote>
- <pre>template <typename X>
-  class Y -> EqualityComparable
-  {
+ 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
+ };
+</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>
- 
+ concept_map EqualityComparable< Y<T> > {};
+</pre>
+ </blockquote>

-</body>
+ --end example]
+ </blockquote>
+
+ <h2>Acknowledgements</h2>

-</html>
\ No newline at end of file
+ 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>

Next message: dave_at_[hidden]: "[Boost-commit] svn:boost r54169 - sandbox/committee/LWG/proposals"
Previous message: christian.schladetsch_at_[hidden]: "[Boost-commit] svn:boost r54167 - in sandbox/monotonic/libs/monotonic/test: . results"

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