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

Subject: [Boost-commit] svn:boost r54182 - sandbox/committee/LWG/proposals
From: dave_at_[hidden]
Date: 2009-06-22 02:29:35

Author: dave
Date: 2009-06-22 02:29:34 EDT (Mon, 22 Jun 2009)
New Revision: 54182
URL: http://svn.boost.org/trac/boost/changeset/54182

Log:
Wrote Summary
Sketched Motivation and Rationales.

Text files modified: 
   sandbox/committee/LWG/proposals/exported-concept-maps.rst |    78 ++++++++++++++++++++++++++++++++++++++++
   1 files changed, 78 insertions(+), 0 deletions(-)

Modified: sandbox/committee/LWG/proposals/exported-concept-maps.rst
==============================================================================
--- sandbox/committee/LWG/proposals/exported-concept-maps.rst	(original)
+++ sandbox/committee/LWG/proposals/exported-concept-maps.rst	2009-06-22 02:29:34 EDT (Mon, 22 Jun 2009)
@@ -13,9 +13,87 @@
 Summary
 =======
 
+Concepts and concept maps can provide default implementations of
+associated functions.  For example, in the following code, ``Num``
+models the ``LessThanComparable`` concept even though it only supplies
+one of four required operators::
+
+  concept LessThanComparable<typename T>
+  {
+      bool operator<(T const& x, T const& y);
+      bool operator>(T const& x, T const& y) { return y < x; }
+      bool operator<=(T const& x, T const& y) { return !(y < x); }
+      bool operator>=(T const& x, T const& y) { return !(x < y); }
+  }
+
+  class Num
+  {
+       friend bool operator<(Num const& x, Num const& y)
+       { ... }
+  };
+  
+  concept_map LessThanComparable<Num>; // OK
+  
+Now all four operators required by ``LessThanComparable`` can be
+applied to ``Num`` in a constrained template where
+``LessThanComparable`` is required::
+
+  template <LessThanComparable X>
+  int f(X& a, X& b)
+  {
+      while (b > a) // Uses operator > from LessThanComparable
+      { ... }
+  }
+
+  Num a, b;
+  int z = f(a, b);  // OK, LessThanComparable supplies operator>
+
+Unfortunately, the same cannot be said of contexts where ``Num`` has
+not been constrained by ``LessThanComparable``::
+
+  int f(Num& a, Num& b)
+  {
+      while (b > a) // error: no operator> defined
+      { ... }
+  }
+
+We propose to allow ``concept_map``\ s to be explicitly “exported” to unconstrained
+contexts like this::
+
+  export concept_map LessThanComparable<Num>; // OK
+  
+Then the unconstrained definition of ``f`` above will work as might be
+expected.  We also propose that concept maps generated with the
+“intentional concept mapping” syntax described in D2916=09-0106 (if it
+is accepted) be exported, so ``Num`` could be declared this way::
+
+  class Num -> LessThanComparable
+  {
+       friend bool operator<(Num const& x, Num const& y)
+       { ... }
+  };
+
 Motivation
 ==========
 
+The status quo creates a disturbing divide between constrained and
+unconstrained code.
+
+* Divide between constrained and unconstrained code.
+* Is Num LessThanComparable?  In constrained code, yes.  In unconstrained code, no.
+
+Rationales
+==========
+
+We considered automatically exporting all ``concept_map``\ s, but that
+could change the meaning of ordinary unconstrained code since
+``concept_map``\ s can be used for post-hoc adaptation, that would
+definitely cause problems
+
+We considered making “``export``” the default, but we believe that the
+“intentional concept mapping syntax” proposed by D2916=09-0106 covers
+a large majority of the cases, so there's no compelling reason to
+increase the risk associated with declaring a ``concept_map``.
 
 Proposed Wording
 ================