From: dgregor_at_[hidden]
Date: 2008-03-03 14:40:10
Author: dgregor
Date: 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
New Revision: 43475
URL: http://svn.boost.org/trac/boost/changeset/43475
Log:
Add issues that come up during LWG review
Added:
sandbox/committee/concepts/issues/issues/issue10.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue11.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue12.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue13.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue14.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue15.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue16.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue17.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue18.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue19.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue2.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue20.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue21.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue22.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue23.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue24.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue25.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue3.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue4.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue5.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue6.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue7.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue8.xml (contents, props changed)
sandbox/committee/concepts/issues/issues/issue9.xml (contents, props changed)
Text files modified:
sandbox/committee/concepts/issues/issues/concepts-template.xml | 13 ++++++-------
sandbox/committee/concepts/issues/section.data | 2 +-
2 files changed, 7 insertions(+), 8 deletions(-)
Modified: sandbox/committee/concepts/issues/issues/concepts-template.xml
==============================================================================
--- sandbox/committee/concepts/issues/issues/concepts-template.xml (original)
+++ sandbox/committee/concepts/issues/issues/concepts-template.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -6,17 +6,16 @@
<issue num="???" status="New">
<title>Your Title</title>
<section><sref ref="00.0.0"/></section>
-<submitter>Your name</submitter>
-<date>29 Feb 1900</date>
+<submitter>Your Name</submitter>
+<date>28 Feb 2008</date>
<discussion>
-<p>
-</p>
+ <p>
+ </p>
</discussion>
<resolution>
-<p>
-</p>
+ <p>
+ </p>
</resolution>
-
</issue>
Added: sandbox/committee/concepts/issues/issues/issue10.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue10.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,20 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="10" status="New">
+<title>Remarks should be notes</title>
+<section><sref ref="[utility.concepts]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p>General semi-editorial issue: almost all of the "Remarks" are
+ actually notes. This is obviously true in the case of Semiregular,
+ for example. Note: this was due to a misunderstanding of the LaTeX
+ macros, because these were all intended to be notes. Considered an
+ editorial issue.</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue11.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue11.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,29 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="11" status="New">
+<title>Semiregular concept is strange</title>
+<section><sref ref="[concept.regular]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p>Exactly why does <tt>Semiregular</tt> exist, and what's the
+ design criterion for deciding which of the requirements
+ in <tt>Regular</tt> should be relaxed for <tt>Semiregular</tt>?
+ Matt's first thought was that <tt>Semiregular</tt> was there to
+ describe the "almost regular" value type of <tt>std::map</tt>, but
+ that's wrong; in this terminology map's value type is
+ neither <tt>Regular</tt> nor <tt>Semiregular</tt>. Mat wonders
+ whether there are any algorithms that need to distinguish between
+ <tt>Regular</tt> and <tt>Semiregular</tt>. A preliminary search
+ shows no use of it in the latest revision of the
+ concepts-in-clause-25 paper. Can we get rid of <tt>Semiregular</tt>?
+ (Note: <tt>Semiregular</tt> is used in the definition of
+ the <tt>InputIterator</tt> concept.)
+ </p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue12.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue12.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,29 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="12" status="Ready">
+<title>Update operator concepts based on "Option #2" change in language specification</title>
+<section><sref ref="[concept.operator]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p>In light of Tuesday night's "option 2" change, all of the
+ operator concepts in 20.1.10 need to have three of the four
+ signatures removed.</p>
+</discussion>
+
+<resolution>
+ <p>Change all of the operator concepts in the same way as we're changing <tt>HasPlus</tt>, as follows:</p>
+
+ <pre>auto concept HasPlus<typename T, typename U = T> {
+ typename result_type;
+ result_type operator+(T const&, U const&);
+ <del>result_type operator+(T const&, U &&);</del>
+ <del>result_type operator+(T &&, U const&);</del>
+ <del>result_type operator+(T &&, U &&);</del>
+}</pre>
+</resolution>
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue13.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue13.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,24 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="13" status="New">
+<title>Naming consistency in [concept.operator]</title>
+<section><sref ref="[concept.operator]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p>Slightly substantive issue: we should consider reviewing the
+ names in 20.1.10 for consistent style. One suggestion is making them
+ consistent with the names of the function objects in 20.5. (Except
+ that some people would like <tt>HasModulus</tt> to have a different
+ name, since x%y isn't strictly speaking the mathematical mod
+ operation, even though the current name is consistent with the 20.5
+ name <tt>std::modulus</tt>. So either that would be an exception to
+ the goal of consistency with 20.5, or it means we need to look for a
+ different naming convention.)</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue14.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue14.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,29 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="14" status="Ready">
+ <title><tt>Addressable</tt> and <tt>const</tt> types</title>
+<section><sref ref="[concept.operator]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p>What does <tt>Addressable</tt> mean for const types? e.g. what
+ happens if you have a constrained template with
+ requires <tt>Addressable<const T></tt>? Is the answer just
+ "don't do that"? Perhaps there should only be one typedef here,
+ not two, and it should be called <tt>result_type</tt>. Ditto for
+ <tt>Dereferenceable</tt>.</p>
+</discussion>
+
+<resolution>
+ <pre>auto concept Addressable<typename T> {
+ typename pointer;
+ <del>typename const_pointer;</del>
+ pointer operator&(T&);
+ <del>const_pointer operator&(const T&);</del>
+}</pre>
+</resolution>
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue15.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue15.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,23 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="15" status="New">
+ <title>Can <tt>Callable</tt>'s function object be an rvalue?</title>
+<section><sref ref="[concept.operator]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p>In <tt>Callable</tt>: can the <tt>F</tt>, the first argument of
+ operator(), be an rvalue? If so, what's the language rule that gives
+ us a yes answer? If not, is it ok to rule that out? (General theme
+ for many of our questions: what is the criterion we use, when we
+ define a concept, to decide whether the concept's functions should
+ take their argument by value, by const reference, by non-const
+ reference, by rvalue reference, or whatever?)</p>
+
+ <p>Note: The function object cannot be an <tt>rvalue</tt>.</p>
+</discussion>
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue16.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue16.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,25 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="16" status="New">
+<title>ArithmeticLike and IntegralLike concepts</title>
+<section><sref ref="[concept.arithmetic]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p>Do we really need <tt>ArithmeticLike</tt>
+ or <tt>IntegralLike</tt>? They're ugly concepts that don't
+ correspond to any mathematical definition, and the requirement of
+ convertibility from long long is a bit weird. The current clause 25
+ proposal uses <tt>IntegralLike</tt>, but maybe it doesn't really
+ need it. Probably those algorithms could be expressed either as real
+ live integer types, built-in types only, or as types that describe
+ an abelian group. <tt>IntegralLike</tt>, complete with things
+ like <tt>&&=</tt>, seems both too constraining and too
+ fuzzy.</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue17.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue17.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,28 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="17" status="New">
+<title>Errors in Allocator concept</title>
+<section><sref ref="[concept.allocator]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p>Allocator, since <tt>pointer</tt> is required to be convertible
+ to <tt>value_type*</tt>, the required convertibility
+ to <tt>void*</tt> is superfluous. Ditto for <tt>const_pointer</tt>
+ to <tt>const void *</tt>. Also, there is a typo in
+ requires <tt>Convertible<const_pointer, const
+ value_type&></tt>. Should be
+ requires <tt>Convertible<const_pointer, const
+ value_type*></tt>.</p>
+
+ <p>In specification of <tt>Allocator::construct</tt> just above
+ 20.1.3 para 11, error requires <tt>Constructible<value_type,
+ V&&></tt> should be requires <tt>Convertible<V,
+ value_type></tt> as in the synopsis.</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue18.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue18.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,24 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="18" status="New">
+<title>Consistent naming for concepts headers</title>
+<section><sref ref="[iterator.concepts]"/></section>
+<submitter>LWG</submitter>
+<date>28 Feb 2008</date>
+
+<discussion>
+ <p>Should <tt><iterator_concepts></tt>
+ and <tt><iterator></tt> be different headers? Probably. It's
+ nice to be able to write constrained templates without pulling in
+ all of <tt><iostream></tt>, for example. On the other hand,
+ which header should things like <tt>std::iterator</tt>
+ and <tt>std::forward_iterator_tag</tt> go in? Also, at a higher
+ level, some consistent naming or locating policy should be firmly
+ established so that random number concepts, iterator concepts, and
+ other concepts all are coherent.</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue19.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue19.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,24 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="19" status="New">
+<title>IteratorBase is an implementation detail</title>
+<section><sref ref="[iterator.concepts]"/></section>
+<submitter>LWG</submitter>
+<date>28 Feb 2008</date>
+
+<discussion>
+ <p>We're not very happy about <tt>IteratorBase</tt>. It doesn't seem
+ like anything that anyone would ever want to constrain a template
+ on; there's no text following its definition to say what it is and
+ what it's for; it appears unused except as, well, a base; it seems
+ more like a macro to save a few lines of typing in the real
+ concepts. Can we get rid of it? Or can we strengthen it into
+ <tt>TrivialIterator</tt> and base all other iterator concepts on
+ <tt>TrivialIterator</tt> instead?
+ </p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue2.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue2.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,24 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="2" status="New">
+<title>Requires clause for Destructible is unclear</title>
+<section><sref ref="[concept.destruct]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p>What does the Requires clause for Destructible actually mean?
+ "All resources owned by the object" is either false (what about a
+ type with a pointer member variable that doesn't call delete in the
+ destructor?) or vacuous (if you define "owned" resources precisely
+ as the resources that are relinquished in the destructor). This is
+ probably another purely syntactic concept: a type that you can use
+ as the target of a pseudo destructor call, or something like
+ that. If we do believe that this is a purely syntactic construct
+ then we might want to consider renaming it as HasDestructor.</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue20.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue20.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,33 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="20" status="New">
+<title>InputIterator default constructibility</title>
+<section><sref ref="[iterator.concepts]"/></section>
+<submitter>LWG</submitter>
+<date>28 Feb 2008</date>
+
+<discussion>
+ <p>We're saying that <tt>InputIterator</tt> is <tt>Semiregular</tt>
+ and <tt>EqualityComparable</tt>, instead of just
+ plain <tt>Regular</tt>. The main reason: in C++03, input iterators
+ aren't necessarily default constructible. (In
+ n2502, <tt>Regular</tt> just adds <tt>DefaultConstructible</tt>
+ and <tt>HeapAllocatable</tt>. But <tt>HeapAllocatable</tt> is a
+ pretty minor thing, and it isn't discussed in C++03 one way or the
+ other.) Wouldn't it be nice if we could just say <tt>Regular</tt>
+ instead? Two options: (1) Say <tt>Regular</tt> and everything it
+ implies in n2502. This implies that all input iterators will be
+ default constructible, which is an incompatibility and a stricter
+ requirements than we have in C++03. It will render some user-defined
+ iterators nonconforming, but maybe that's a small price to pay. (2)
+ Get rid of the <tt>Semiregular</tt> concept, but
+ remove <tt>DefaultConstructible</tt> from <tt>Regular</tt>. Arguably
+ default construction isn't a fundamental part of the notion of
+ regularity, and on the occasions that we want "regular and default
+ constructible" we should say so explicitly.</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue21.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue21.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,28 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="21" status="New">
+ <title>Iterator <tt>difference_type</tt> requirements</title>
+<section><sref ref="[input.iterators]"/></section>
+<submitter>LWG</submitter>
+<date>28 Feb 2008</date>
+
+<discussion>
+ <p><tt>InputIterator</tt> currently requires that its difference
+ type be both an <tt>IntegerType</tt>
+ and <tt>SignedIntegralLike</tt>. There are two issues here. First,
+ why do we need to require both? Answer: one of those is a
+ compiler-generated concept saying that it must be one of a specific
+ list of built-in types, but it doesn't declare anything about the
+ operations, so it doesn't allow you to actually write things like
+ +. But that's very weird. If we know that we've constrained it to be
+ one of a small number of types, shouldn't we be able to use those
+ operations that those types all have in common? Second, just why are
+ we requiring it to be one of the types in that list? If I have my
+ own type that I can use for counting (i.e. an abelian group), then
+ why can't I use it for the iterator's difference type?</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue22.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue22.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,33 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="22" status="New">
+ <title>Oddly-placed and missing <tt>InputIterator</tt> requirements</title>
+<section><sref ref="[input.iterators]"/></section>
+<submitter>LWG</submitter>
+<date>28 Feb 2008</date>
+
+<discussion>
+ <p>24.1.1 paragraphs 8 and 9 seem very oddly placed. They seem to be
+ discussing the semantics of <tt>operator==</tt>, but textually
+ they appear to be underneath the signature
+ for <tt>operator-></tt>. This is probably a purely editorial
+ issue. Another purely editorial issue: "any" should be capitalized
+ at the beginning of the second sentence of paragraph 11.</p>
+ <p>There's something missing in 24.1.1. The semantics of <tt>*r++</tt> has
+ gotten lost in the shuffle. The old requirements table said that
+ <tt>*r++</tt> gave us the value we would have gotten before the
+ increment, but the n2500 version doesn't say that. Based on the
+ words in n2500, all we really know about <tt>*r++</tt> is that it
+ returns some unspecified value that's convertible
+ to <tt>value_type</tt>. Similar issues apply
+ in <tt>OutputIterator</tt>.</p>
+</discussion>
+
+<resolution>
+ <p>
+ </p>
+</resolution>
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue23.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue23.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,36 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="23" status="New">
+<title>Output iterators without value types</title>
+<section><sref ref="[output.iterators]"/></section>
+<submitter>LWG</submitter>
+<date>28 Feb 2008</date>
+
+<discussion>
+ <p>24.1.2 preserves the C++03 notion that output iterators don't
+ actually have value types (see, for example, 24.1.2 paragraph 3,
+ saying that an output iterator may permit output of many different
+ value types). Is this something we really want to preserve for
+ conceptized C++09? There are a few real-world output iterators that
+ support multiple output types, but very few. For most users, the
+ fact that we don't have a specific output types is much more a
+ nuisance than anything else. This is another issue where we have a
+ choice between rationalizing the current requirements or preserving
+ them in every last corner case, and we should consider doing the
+ former. Concretely, in terms of the n2500 notation: most users
+ probably want to use the <tt>BasicOutputIterator</tt> concept,
+ not <tt>OutputIterator</tt>. We should consider
+ renaming <tt>BasicOutputIterator</tt> to <tt>OutputIterator</tt>,
+ and either getting rid of the concept that n2500
+ calls <tt>OutputIterator</tt> or renaming it
+ to <tt>BackwardCompatibilityOutputIteratorWithoutValueType</tt>.</p>
+</discussion>
+
+<resolution>
+ <p>
+ </p>
+</resolution>
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue24.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue24.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,19 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="24" status="New">
+<title>Convertible and CopyConstructible have different argument orders</title>
+<section><sref ref="[concept.convertible]"/></section>
+<submitter>LWG</submitter>
+<date>28 Feb 2008</date>
+
+<discussion>
+ <p>The order of argument in <tt>Convertible</tt>
+ and <tt>Constructible</tt> is different. We should consider changing
+ the name and/or argument order of <tt>Convertible</tt> to make it
+ clearer which argument goes where.</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue25.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue25.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,33 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="25" status="New">
+ <title>Lost normative semantics of <tt>ForwardIterator</tt></title>
+<section><sref ref="[forward.iterators]"/></section>
+<submitter>LWG</submitter>
+<date>28 Feb 2008</date>
+
+<discussion>
+ <p>We seem to have lost all normative text that describes the
+ semantics of forward iterators. Some of the semantics from table 98
+ have just disappeared, and the n2500 text has very little to say
+ about substantive ways in which constant forward iterators differ
+ from input iterators. We've lost the requirement that <tt>r ==
+ s</tt> implies <tt>++r == ++s</tt>. (It now appears only in
+ nonnormative text.) There's nothing saying that forward iterators
+ are allowed to be multipass. Forward iterators are a good use case
+ for the axiom feature.</p>
+
+ <p>One of the other important axioms for forward iterators is
+ that <tt>a == b</tt> iff <tt>a</tt> and <tt>b</tt> are the same
+ object. This axiom got moved to input iterators (but not using the
+ axiom feature), where it does not belong. That assertion is not true
+ for input iterators in general, or for some of the specific input
+ iterators in the standard. What's novel about forward iterators, as
+ opposed to input iterators, is that a forward iterator points to a
+ specific memory location.</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue3.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue3.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,23 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="3" status="New">
+<title>Naming of Constructible/DefaultConstructible concepts</title>
+<section><sref ref="[concept.construct]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p><tt>Constructible</tt> and <tt>DefaultConstructible</tt> don't
+ have any semantics, so they should have the prefix <tt>Has</tt>.</p>
+</discussion>
+
+<resolution>
+ <p>Rename <tt>Constructible</tt> to <tt>HasConstructor</tt>,
+ and rename <tt>DefaultConstructible</tt> to
+ <tt>HasDefaultConstructor</tt></p>
+</resolution>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue4.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue4.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,22 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="4" status="New">
+<title>MoveConstructible should refine Constructible</title>
+<section><sref ref="[concept.copymove]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p>We should consider saying that <tt>MoveConstructible</tt> is a
+ refinement of an appropriate specialization
+ of <tt>Constructible</tt>, not
+ just <tt>Destructible</tt>. Specifically, one would think
+ that <tt>MoveConstructible<T></tt> is a refinement
+ of <tt>Constructible<T, T&&></tt>. In that case, the
+ body of <tt>MoveConstructible</tt> would go away.</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue5.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue5.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,24 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="5" status="New">
+<title>Inconsistent naming between concepts and type traits</title>
+<section><sref ref="[utility.concepts]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+<p>General issue: many of these core concepts, including
+ <tt>CopyConstructible</tt>, <tt>TriviallyCopyConstructible</tt>,
+and <tt>ObjectType</tt>, mirror existing type traits
+names. Essentially, type traits are a mechanism used in unconstrained
+templates and concepts express something very similar in constrained
+code. We should consider a uniform naming convention, in places where
+the correspondence exists, to make the connection clearer. This is one
+ motivation for using Has* and Is* uniformly.
+</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue6.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue6.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,28 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="6" status="DR">
+<title>MoveAssignable assignment operator is incorrect</title>
+<section><sref ref="[concept.copymove]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p>Editorial issue in <tt>MoveAssignable</tt>: the function
+ signature is different in the concept synopsis than it is in
+ paragraph 6, and inconsistent with <tt>CopyAssignable</tt></p>
+</discussion>
+
+<resolution>
+ <p>Update the definition of <tt>MoveAssignable</tt> in paragraph 6
+ of N2502 as follows:</p>
+
+ <pre>auto concept MoveAssignable<typename T, typename U = T> {
+ typename result_type;
+ result_type <ins>T::</ins>operator=(<del>T&, </del>U&&);
+}</pre>
+</resolution>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue7.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue7.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,24 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="7" status="New">
+ <title>Meaning of "equivalent" in <tt>MoveAssignable</tt></title>
+ <section><sref ref="[concept.copymove]"/></section>
+ <submitter>LWG</submitter>
+ <date>27 Feb 2008</date>
+
+<discussion>
+ <p>Substantive issue in <tt>MoveAssignable</tt>: the postcondition
+ is that the constructed <tt>T</tt> object is equivalent to the old value of
+ <tt>rv</tt>. What does equivalent mean? It's especially
+ problematic when <tt>U</tt> and <tt>T</tt> are different types,
+ but even for the same type it's not a defined term and not
+ completely clear how it should be defined. (One might imagine that
+ for the same type it should be defined in terms
+ of <tt>operator==</tt>, but this concept doesn't mention that
+ operator.)</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue8.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue8.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,25 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="8" status="New">
+ <title><tt>Swappable</tt> and rvalue references</title>
+<section><sref ref="[concept.copymove]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p>Is <tt>Swappable</tt> right, or does it also need
+ a <tt>T&&</tt> signature? We think that <tt>Swappable</tt>
+ does need to cover rvalue reference and that this concept probably
+ needs to be changed, especially in light of this week's tinkering
+ with <tt>swap</tt> and <tt>Swappable</tt> (LWG issue 742), but (a)
+ Nobody in the room understands rvalue references well enough to
+ say for sure, and (b) We aren't sure whether the relaxed signature
+ checking from Tuesday night has any impact. We think the answer
+ might be to put in one <tt>T&</tt> signature, and two other
+ signatures that default to the first.</p>
+</discussion>
+
+</issue>
Added: sandbox/committee/concepts/issues/issues/issue9.xml
==============================================================================
--- (empty file)
+++ sandbox/committee/concepts/issues/issues/issue9.xml 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -0,0 +1,27 @@
+<?xml version='1.0' encoding='iso-8859-1' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd" [
+ <!ENTITY nbsp " ">
+] >
+
+<issue num="9" status="New">
+<title>Memory-allocation concepts are too fine-grained</title>
+<section><sref ref="[concept.memory]"/></section>
+<submitter>LWG</submitter>
+<date>27 Feb 2008</date>
+
+<discussion>
+ <p><tt>Newable</tt> and <tt>Deletable</tt>
+ and <tt>HeapAllocatable</tt> are awfully fine grained and low
+ level. Can we get rid of them, or at least consolidate them? Yes,
+ it's possible to write types that can be created on the stack but
+ not with <tt>new</tt>, but do our library algorithms really need to
+ distinguish between constructable, new-able, and
+ heap-allocatable?</p>
+</discussion>
+
+<resolution>
+<p>
+</p>
+</resolution>
+
+</issue>
Modified: sandbox/committee/concepts/issues/section.data
==============================================================================
--- sandbox/committee/concepts/issues/section.data (original)
+++ sandbox/committee/concepts/issues/section.data 2008-03-03 14:40:08 EST (Mon, 03 Mar 2008)
@@ -832,7 +832,7 @@
23.4.4.1 [unord.multiset.cnstr]
23.4.4.2 [unord.multiset.swap]
24 [iterators]
- 24.1 [iterator.requirements]
+ 24.1 [iterator.concepts]
24.1.1 [input.iterators]
24.1.2 [output.iterators]
24.1.3 [forward.iterators]