Boost-Commit :

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r54169 - sandbox/committee/LWG/proposals
From: dave_at_[hidden]
Date: 2009-06-21 23:02:26

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

Author: dave
Date: 2009-06-21 23:02:26 EDT (Sun, 21 Jun 2009)
New Revision: 54169
URL: http://svn.boost.org/trac/boost/changeset/54169

Log:
These are my suggested edits.

Text files modified:
sandbox/committee/LWG/proposals/Intentional | 149 ++++++++++++++++-----------------------
1 files changed, 62 insertions(+), 87 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 23:02:26 EDT (Sun, 21 Jun 2009)
@@ -38,34 +38,32 @@

 <h2>Introduction</h2>

- Uses of C++0x concept maps include:
+ A C++0x concept map can be useful (among other things) as:

 <ul>
- <li>Declaring the intention that a class models a concept, expressed in
- code rather than in documentation. 
-  </li>
+ <li>A declaration to the compiler of 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
+ <li>A declaration 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:
+ <li>A tool for the interactive model development that causes the compiler
+ to prompt the author for all required structural elements.</li>
+ </ul>

- <blockquote>
- <pre>
+ As of CD1, concept maps used for this purpose are often empty:
+ <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:
@@ -73,99 +71,88 @@
 <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 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 location of the concept maps after the class definition tends to
+ tends to push the important activity of constraining the class until
+ later in the class' development cycle, but it best occurs early (probably
+ first).</li>

- <li>The empty concept maps are excessively verbose.</li>
+ <li>Empty concept maps are excessively verbose.</li>
 </ul>

- This paper proposes that the above could also be written as:
-
- <blockquote>
- <pre>
+ This paper proposes that the above code could also be written as:
+ <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
+ 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>
+ We did consider using <code>requires</code>, but it was rejected on the
+ grounds that it would make a <code>concept_map</code> look too much like a
+ 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:
+ <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>
+</pre>you're just constraining X, nothing more.  It's pure requirement
+checking.  However, when you write:
+ <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>you're generating a concept map for all specializations of
+<code>Y</code>, with all that that implies (e.g. generation of defaults,
+Y<T> can be used where EqualityComparable is required, etc):
+ <pre>
+// generated 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.
+ say "my type models concepts XXX, YYY, and ZZZ, and please tell me if I get
+ it wrong (structurally)", and to 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, more
+ expressive, and less verbose in the common case where one is
+ intentionally creating a model of a known concept, however empty
+ <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.
+
+ 

 <h2>Proposed Wording</h2>

@@ -233,26 +220,21 @@
 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
+ A mapped-concept-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>
+ <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>
+ <pre>
template <typename X>
 class Y -> EqualityComparable
 {
@@ -260,15 +242,11 @@
 };
</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
+ The above implicitly generates the following concept map:
+ <pre>
template <typename T>
 concept_map EqualityComparable< Y<T> > {};
</pre>
- </blockquote>

 --end example]
 </blockquote>
@@ -279,8 +257,5 @@
 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: christian.schladetsch_at_[hidden]: "[Boost-commit] svn:boost r54170 - in sandbox/monotonic/libs/monotonic/test: . results"
Previous message: dave_at_[hidden]: "[Boost-commit] svn:boost r54168 - sandbox/committee/LWG/proposals"

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