Doc. no. N3284=11-0054
Date: 2011-03-25
Project: Programming Language C++
Reply to: Alisdair Meredith <lwgchair@gmail.com>

C++ Standard Library Active Issues List (Madrid Resolutions)

Revised 2011-03-25 at 10:03:28 UTC

Reference ISO/IEC IS 14882:2003(E)

Also see:

The purpose of this document is to record the status of issues which have come before the Library Working Group (LWG) of the INCITS PL22.16 and ISO WG21 C++ Standards Committee. Issues represent potential defects in the ISO/IEC IS 14882:2003(E) document.

This document contains only library issues which are actively being considered by the Library Working Group, i.e., issues which have a status of New, Open, Ready, or Review. See Library Defect Reports List for issues considered defects and Library Closed Issues List for issues considered closed.

The issues in these lists are not necessarily formal ISO Defect Reports (DR's). While some issues will eventually be elevated to official Defect Report status, other issues will be disposed of in other ways. See Issue Status.

Prior to Revision 14, library issues lists existed in two slightly different versions; a Committee Version and a Public Version. Beginning with Revision 14 the two versions were combined into a single version.

This document includes [bracketed italicized notes] as a reminder to the LWG of current progress on issues. Such notes are strictly unofficial and should be read with caution as they may be incomplete or incorrect. Be aware that LWG support for a particular resolution can quickly change if new viewpoints or killer examples are presented in subsequent discussions.

For the most current official version of this document see http://www.open-std.org/jtc1/sc22/wg21/. Requests for further information about this document should include the document number above, reference ISO/IEC 14882:2003(E), and be submitted to Information Technology Industry Council (ITI), 1250 Eye Street NW, Washington, DC 20005.

Public information as to how to obtain a copy of the C++ Standard, join the standards committee, submit an issue, or comment on an issue can be found in the comp.std.c++ FAQ.

How to submit an issue

  1. Mail your issue to the author of this list.
  2. Specify a short descriptive title. If you fail to do so, the subject line of your mail will be used as the issue title.
  3. If the "From" on your email is not the name you wish to appear as issue submitter, then specify issue submitter.
  4. Provide a brief discussion of the problem you wish to correct. Refer to the latest working draft or standard using [section.tag] and paragraph numbers where appropriate.
  5. Provide proposed wording. This should indicate exactly how you want the standard to be changed. General solution statements belong in the discussion area. This area contains very clear and specific directions on how to modify the current draft. If you are not sure how to word a solution, you may omit this part. But your chances of a successful issue greatly increase if you attempt wording.
  6. It is not necessary for you to use html markup. However, if you want to, you can <ins>insert text like this</ins> and <del>delete text like this</del>. The only strict requirement is to communicate clearly to the list maintainer exactly how you want your issue to look.
  7. It is not necessary for you to specify other html font/formatting mark-up, but if you do the list maintainer will attempt to respect your formatting wishes (as described by html markup, or other common idioms).
  8. It is not necessary for you to specify open date or last modified date (the date of your mail will be used).
  9. It is not necessary for you to cross reference other issues, but you can if you like. You do not need to form the hyperlinks when you do, the list maintainer will take care of that.
  10. One issue per email is best.
  11. Between the time you submit the issue, and the next mailing deadline (date at the top of the Revision History), you own this issue. You control the content, the stuff that is right, the stuff that is wrong, the format, the misspellings, etc. You can even make the issue disappear if you want. Just let the list maintainer know how you want it to look, and he will try his best to accommodate you. After the issue appears in an official mailing, you no longer enjoy exclusive ownership of it.

Revision History

Issue Status

New - The issue has not yet been reviewed by the LWG. Any Proposed Resolution is purely a suggestion from the issue submitter, and should not be construed as the view of LWG.

Open - The LWG has discussed the issue but is not yet ready to move the issue forward. There are several possible reasons for open status:

A Proposed Resolution for an open issue is still not be construed as the view of LWG. Comments on the current state of discussions are often given at the end of open issues in an italic font. Such comments are for information only and should not be given undue importance.

Deferred - The LWG has discussed the issue, is not yet ready to move the issue forward, but neither does it deem the issue significant enough to delay publishing a standard or Technical Report. A typical deferred issue would be seeking to clarify wording that might be technically correct, but easily mis-read.

A Proposed Resolution for a deferred issue is still not be construed as the view of LWG. Comments on the current state of discussions are often given at the end of open issues in an italic font. Such comments are for information only and should not be given undue importance.

Dup - The LWG has reached consensus that the issue is a duplicate of another issue, and will not be further dealt with. A Rationale identifies the duplicated issue's issue number.

NAD - The LWG has reached consensus that the issue is not a defect in the Standard.

NAD Editorial - The LWG has reached consensus that the issue can either be handled editorially, or is handled by a paper (usually linked to in the rationale).

NAD Concepts - The LWG has reached consensus that the issue is NAD for now, but represents a real issue when the library is done with language-supported concepts.

NAD Future - In addition to the regular status, the LWG believes that this issue should be revisited at the next revision of the standard.

Review - Exact wording of a Proposed Resolution is now available for review on an issue for which the LWG previously reached informal consensus.

Ready - The LWG has reached consensus that the issue is a defect in the Standard, the Proposed Resolution is correct, and the issue is ready to forward to the full committee for further action as a Defect Report (DR).

Resolved - The LWG has reached consensus that the issue is a defect in the Standard, but the resolution adopted to resolve the issue came via some other mechanism than this issue in the list - typically by applying a formal paper, occasionally as a side effect of consolidating several interacting issue resolutions into a single issue.

DR - (Defect Report) - The full WG21/PL22.16 committee has voted to forward the issue to the Project Editor to be processed as a Potential Defect Report. The Project Editor reviews the issue, and then forwards it to the WG21 Convenor, who returns it to the full committee for final disposition. This issues list accords the status of DR to all these Defect Reports regardless of where they are in that process.

TC1 - (Technical Corrigenda 1) - The full WG21/PL22.16 committee has voted to accept the Defect Report's Proposed Resolution as a Technical Corrigenda. Action on this issue is thus complete and no further action is possible under ISO rules.

CD1 - (Committee Draft 2008) - The full WG21/PL22.16 committee has voted to accept the Defect Report's Proposed Resolution into the Fall 2008 Committee Draft.

TRDec - (Decimal TR defect) - The LWG has voted to accept the Defect Report's Proposed Resolution into the Decimal TR. Action on this issue is thus complete and no further action is expected.

WP - (Working Paper) - The proposed resolution has not been accepted as a Technical Corrigendum, but the full WG21/PL22.16 committee has voted to apply the Defect Report's Proposed Resolution to the working paper.

Tentatively - This is a status qualifier. The issue has been reviewed online, or at an unofficial meeting, but not in an official meeting, and some support has been formed for the qualified status. Tentatively qualified issues may be moved to the unqualified status and forwarded to full committee (if Ready) within the same meeting. Unlike Ready issues, Tentatively Ready issues will be reviewed in subcommittee prior to forwarding to full committee. When a status is qualified with Tentatively, the issue is still considered active.

Pending - This is a status qualifier. When prepended to a status this indicates the issue has been processed by the committee, and a decision has been made to move the issue to the associated unqualified status. However for logistical reasons the indicated outcome of the issue has not yet appeared in the latest working paper.

Issues are always given the status of New when they first appear on the issues list. They may progress to Open or Review while the LWG is actively working on them. When the LWG has reached consensus on the disposition of an issue, the status will then change to Dup, NAD, or Ready as appropriate. Once the full J16 committee votes to forward Ready issues to the Project Editor, they are given the status of Defect Report ( DR). These in turn may become the basis for Technical Corrigenda (TC), or are closed without action other than a Record of Response (RR ). The intent of this LWG process is that only issues which are truly defects in the Standard move to the formal ISO DR status.

Active Issues

1169. num_get not fully compatible with strto*

Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: Deferred Submitter: Cosmin Truta Opened: 2009-07-04 Last modified: 2011-03-24

View other active issues in [facet.num.get.virtuals].

View all other issues in [facet.num.get.virtuals].

View all issues with Deferred status.

Discussion:

As specified in the latest draft, N2914, num_get is still not fully compatible with the following C functions: strtoul, strtoull, strtof and strtod.

In C, when conversion of a string to an unsigned integer type falls outside the representable range, strtoul and strtoull return ULONG_MAX and ULLONG_MAX, respectively, regardless whether the input field represents a positive or a negative value. On the other hand, the result of num_get conversion of negative values to unsigned integer types is zero. This raises a compatibility issue.

Moreover, in C, when conversion of a string to a floating-point type falls outside the representable range, strtof, strtod and strtold return ±HUGE_VALF, ±HUGE_VAL and ±HUGE_VALL, respectively. On the other hand, the result of num_get conversion of such out-of-range floating-point values results in the most positive/negative representable value. Although many C library implementations do implement HUGE_VAL (etc.) as the highest representable (which is, usually, the infinity), this isn't required by the C standard. The C library specification makes no statement regarding the value of HUGE_VAL and friends, which potentially raises the same compatibility issue as in the above case of unsigned integers. In addition, neither C nor C++ define symbolic constants for the maximum representable floating-point values (they only do so only for the maximum representable finite floating-point values), which raises a usability issue (it would be hard for the programmer to check the result of num_get against overflow).

As such, we propose to adjust the specification of num_get to closely follow the behavior of all of its underlying C functions.

[ 2010 Rapperswil: ]

Some concern that this is changing the specification for an existing C++03 function, but it was pointed out that this was underspecified as resolved by issue 23. This is clean-up for that issue in turn. Some concern that we are trying to solve the same problem in both clause 22 and 27.

Bill: There's a change here as to whether val is stored to in an error case.

Pablo: Don't think this changes whether val is stored to or not, but changes the value that is stored.

Bill: Remembers having skirmishes with customers and testers as to whether val is stored to, and the resolution was not to store in error cases.

Howard: Believes since C++03 we made a change to always store in overflow.

Everyone took some time to review the issue.

Pablo: C++98 definitely did not store any value during an error condition.

Dietmar: Depends on the question of what is considered an error, and whether overflow is an error or not, which was the crux of LWG 23.

Pablo: Yes, but given the "zero, if the conversion function fails to convert the entire field", we are requiring every error condition to store.

Bill: When did this happen?

Alisdair: One of the last two or three meetings.

Dietmar: To store a value in case of failure is a very bad idea.

Move to Open, needs more study.

[2011-03-24 Madrid meeting]

Move to deferred

Proposed resolution:

Change 22.4.2.1.2 [facet.num.get.virtuals] as follows:

Stage 3: The sequence of chars accumulated in stage 2 (the field) is converted to a numeric value by the rules of one of the functions declared in the header <cstdlib>:

The numeric value to be stored can be one of:

The resultant numeric value is stored in val. If the conversion function fails to convert the entire field, or if the field represents a value outside the range of representable values, ios_base::failbit is assigned to err.

1175. unordered complexity

Section: 23.2.5 [unord.req] Status: Deferred Submitter: Pablo Halpern Opened: 2009-07-17 Last modified: 2011-03-24

View other active issues in [unord.req].

View all other issues in [unord.req].

View all issues with Deferred status.

Discussion:

When I look at the unordered_* constructors, I think the complexity is poorly described and does not follow the style of the rest of the standard.

The complexity for the default constructor is specified as constant. Actually, it is proportional to n, but there are no invocations of value_type constructors or other value_type operations.

For the iterator-based constructor the complexity should be:

Complexity: exactly n calls to construct value_type from InputIterator::value_type (where n = distance(f,l)). The number of calls to key_equal::operator() is proportional to n in the average case and n*n in the worst case.

[ 2010 Rapperswil: ]

Concern that the current wording may require O(1) where that cannot be delivered. We need to look at both the clause 23 requirements tables and the constructor description of each unordered container to be sure.

Howard suggests NAD Editorial as we updated the container requirement tables since this issue was written.

Daniel offers to look deeper, and hopefully produce wording addressing any outstanding concerns at the next meeting.

Move to Open.

[2011-02-26: Daniel provides wording]

I strongly suggest to clean-up the differences between requirement tables and individual specifications. In the usual way, the most specific specifications wins, which is in this case the wrong one. In regard to the concern expressed about missing DefaultConstructible requirements of the value type I disagree: The function argument n is no size-control parameter, but only some effective capacity parameter: No elements will be value-initialized by these constructors. The necessary requirement for the value type, EmplaceConstructible into *this, is already listed in Table 103 — Unordered associative container requirements. Another part of the proposed resolution is the fact that there is an inconsistency of the complexity counting when both a range and a bucket count is involved compared to constructions where only bucket counts are provided: E.g. the construction X a(n); has a complexity of n bucket allocations, but this part of the work is omitted for X a(i, j, n);, even though it is considerable larger (in the average case) for n ≫ distance(i, j).

[2011-03-24 Madrid meeting]

Move to deferred

Proposed resolution:

  1. Modify the following rows in Table 103 — Unordered associative container requirements to add the explicit bucket allocation overhead of some constructions. As editorial recommendation it is suggested not to shorten the sum 𝒪(n) + 𝒪(N) to 𝒪(n + N), because two different work units are involved.

    Table 103 — Unordered associative container requirements (in addition to container)
    Expression Return type Assertion⁄note pre-⁄post-condition Complexity
    …
    X(i, j, n, hf, eq)
    X a(i, j, n, hf, eq)     		X …
    Effects: Constructs an empty container with at least n
    buckets, using hf as the hash function and eq as the key
    equality predicate, and inserts elements from [i, j) into it.     		Average case 𝒪(n) + 𝒪(N) (N is distance(i, j)),
    worst case 𝒪(n) + 𝒪(N2)
    X(i, j, n, hf)
    X a(i, j, n, hf)     		X …
    Effects: Constructs an empty container with at least n
    buckets, using hf as the hash function and key_equal() as the key
    equality predicate, and inserts elements from [i, j) into it.     		Average case 𝒪(n) + 𝒪(N) (N is distance(i, j)),
    worst case 𝒪(n) + 𝒪(N2)
    X(i, j, n)
    X a(i, j, n)     		X …
    Effects: Constructs an empty container with at least n
    buckets, using hasher() as the hash function and key_equal() as the key
    equality predicate, and inserts elements from [i, j) into it.     		Average case 𝒪(n) + 𝒪(N) (N is distance(i, j)),
    worst case 𝒪(n) + 𝒪(N2)
    …

  2. Modify 23.5.4.2 [unord.map.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some editorial oversight.):

    explicit unordered_map(size_type n = see below,
                       const hasher& hf = hasher(),
                       const key_equal& eql = key_equal(),
                       const allocator_type& a = allocator_type());

    1 Effects: Constructs an empty unordered_map using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_map. max_load_factor() returns 1.0.

    2 Complexity: Constant if n is not provided, otherwise linear in n to construct the buckets. 

    template <class InputIterator>
unordered_map(InputIterator f, InputIterator l,
              size_type n = see below,
              const hasher& hf = hasher(),
              const key_equal& eql = key_equal(),
              const allocator_type& a = allocator_type());

    3 Effects: Constructs an empty unordered_map using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_map. Then inserts elements from the range [f, l). max_load_factor() returns 1.0.

    4 Complexity: Average case linear, worst case quadraticConstant if n is not provided, else linear in n to construct the buckets. In the average case linear in N and in the worst case quadratic in N to insert the elements, where N is equal to distance(f, l).

  3. Modify 23.5.5.2 [unord.multimap.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some editorial oversight.):

    explicit unordered_multimap(size_type n = see below,
                            const hasher& hf = hasher(),
                            const key_equal& eql = key_equal(),
                            const allocator_type& a = allocator_type());

    1 Effects: Constructs an empty unordered_multimap using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_multimap. max_load_factor() returns 1.0.

    2 Complexity: Constant if n is not provided, otherwise linear in n to construct the buckets. 

    template <class InputIterator>
unordered_multimap(InputIterator f, InputIterator l,
                   size_type n = see below,
                   const hasher& hf = hasher(),
                   const key_equal& eql = key_equal(),
                   const allocator_type& a = allocator_type());

    3 Effects: Constructs an empty unordered_multimap using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_multimap. Then inserts elements from the range [f, l). max_load_factor() returns 1.0.

    4 Complexity: Average case linear, worst case quadraticConstant if n is not provided, else linear in n to construct the buckets. In the average case linear in N and in the worst case quadratic in N to insert the elements, where N is equal to distance(f, l).

  4. Modify 23.5.6.2 [unord.set.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some editorial oversight.):

    explicit unordered_set(size_type n = see below,
                       const hasher& hf = hasher(),
                       const key_equal& eql = key_equal(),
                       const allocator_type& a = allocator_type());

    1 Effects: Constructs an empty unordered_set using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_set. max_load_factor() returns 1.0.

    2 Complexity: Constant if n is not provided, otherwise linear in n to construct the buckets. 

    template <class InputIterator>
unordered_set(InputIterator f, InputIterator l,
              size_type n = see below,
              const hasher& hf = hasher(),
              const key_equal& eql = key_equal(),
              const allocator_type& a = allocator_type());

    3 Effects: Constructs an empty unordered_set using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_set. Then inserts elements from the range [f, l). max_load_factor() returns 1.0.

    4 Complexity: Average case linear, worst case quadraticConstant if n is not provided, else linear in n to construct the buckets. In the average case linear in N and in the worst case quadratic in N to insert the elements, where N is equal to distance(f, l).

  5. Modify 23.5.7.2 [unord.multiset.cnstr] p. 1-4 as indicated (The edits of p. 1 and p. 3 attempt to fix some editorial oversight.):

    explicit unordered_multiset(size_type n = see below,
                            const hasher& hf = hasher(),
                            const key_equal& eql = key_equal(),
                            const allocator_type& a = allocator_type());

    1 Effects: Constructs an empty unordered_multiset using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_multiset. max_load_factor() returns 1.0.

    2 Complexity: Constant if n is not provided, otherwise linear in n to construct the buckets. 

    template <class InputIterator>
unordered_multiset(InputIterator f, InputIterator l,
                   size_type n = see below,
                   const hasher& hf = hasher(),
                   const key_equal& eql = key_equal(),
                   const allocator_type& a = allocator_type());

    3 Effects: Constructs an empty unordered_multiset using the specified hash function, key equality function, and allocator, and using at least n buckets. If n is not provided, the number of buckets is implementation-definedimpldefdefault number of buckets in unordered_multiset. Then inserts elements from the range [f, l). max_load_factor() returns 1.0.

    4 Complexity: Average case linear, worst case quadraticConstant if n is not provided, else linear in n to construct the buckets. In the average case linear in N and in the worst case quadratic in N to insert the elements, where N is equal to distance(f, l).

1213. Meaning of valid and singular iterator underspecified

Section: 24.2 [iterator.requirements] Status: Deferred Submitter: Daniel Krügler Opened: 2009-09-19 Last modified: 2011-03-24

View all other issues in [iterator.requirements].

View all issues with Deferred status.

Discussion:

The terms valid iterator and singular aren't properly defined. The fuzziness of those terms became even worse after the resolution of 208 (including further updates by 278). In 24.2 [iterator.requirements] as of N2723 the standard says now:

5 - These values are called past-the-end values. Values of an iterator i for which the expression *i is defined are called dereferenceable. The library never assumes that past-the-end values are dereferenceable. Iterators can also have singular values that are not associated with any container. [...] Results of most expressions are undefined for singular values; the only exceptions are destroying an iterator that holds a singular value and the assignment of a non-singular value to an iterator that holds a singular value. [...] Dereferenceable values are always non-singular.

10 - An invalid iterator is an iterator that may be singular.

First, issue 208 intentionally removed the earlier constraint that past-the-end values are always non-singular. The reason for this was to support null pointers as past-the-end iterators of e.g. empty sequences. But there seem to exist different views on what a singular (iterator) value is. E.g. according to the SGI definition a null pointer is not a singular value:

Dereferenceable iterators are always nonsingular, but the converse is not true. For example, a null pointer is nonsingular (there are well defined operations involving null pointers) even thought it is not dereferenceable.

and proceeds:

An iterator is valid if it is dereferenceable or past-the-end.

Even if the standard prefers a different meaning of singular here, the change was incomplete, because by restricting feasible expressions of singular iterators to destruction and assignment isn't sufficient for a past-the-end iterator: Of-course it must still be equality-comparable and in general be a readable value.

Second, the standard doesn't clearly say whether a past-the-end value is a valid iterator or not. E.g. 20.6.12 [specialized.algorithms]/1 says:

In all of the following algorithms, the formal template parameter ForwardIterator is required to satisfy the requirements of a forward iterator (24.1.3) [..], and is required to have the property that no exceptions are thrown from [..], or dereference of valid iterators.

The standard should make better clear what "singular pointer" and "valid iterator" means. The fact that the meaning of a valid value has a core language meaning doesn't imply that for an iterator concept the term "valid iterator" has the same meaning.

Let me add a final example: In X [allocator.concepts.members] of N2914 we find: 

pointer X::allocate(size_type n);

11 Returns: a pointer to the allocated memory. [Note: if n == 0, the return value is unspecified. —end note]

[..] 

void X::deallocate(pointer p, size_type n);

Preconditions: p shall be a non-singular pointer value obtained from a call to allocate() on this allocator or one that compares equal to it.

If singular pointer value would include null pointers this make the preconditions unclear if the pointer value is a result of allocate(0): Since the return value is unspecified, it could be a null pointer. Does that mean that programmers need to check the pointer value for a null value before calling deallocate?

[ 2010-11-09 Daniel comments: ]

A later paper is in preparation.

[ 2010 Batavia: ]

Doesn't need to be resolved for Ox

Proposed resolution:

Consider to await the paper.

1214. Insufficient/inconsistent key immutability requirements for associative containers

Section: 23.2.4 [associative.reqmts] Status: Deferred Submitter: Daniel Krügler Opened: 2009-09-20 Last modified: 2011-03-24

View other active issues in [associative.reqmts].

View all other issues in [associative.reqmts].

View all issues with Deferred status.

Discussion:

Scott Meyers' mentions on a recent posting on c.s.c++ some arguments that point to an incomplete resolution of 103 and to an inconsistency of requirements on keys in ordered and unordered associative containers:

1) 103 introduced the term immutable without defining it in a unique manner in 23.2.4 [associative.reqmts]/5:

[..] Keys in an associative container are immutable.

According to conventional dictionaries immutable is an unconditional way of saying that something cannot be changed. So without any further explicit allowance a user always runs into undefined behavior if (s)he attempts to modify such a key. IMO this was not the intend of the committee to resolve 103 in that way because the comments suggest an interpretation that should give any user the freedom to modify the key in an explicit way provided it would not affect the sort order in that container.

2) Another observation was that surprisingly no similar 'safety guards' exists against unintentional key changes for the unordered associative containers, specifically there is no such requirement as in 23.2.4 [associative.reqmts]/6 that "both iterator and const_iterator are constant iterators". But the need for such protection against unintentional changes as well as the constraints in which manner any explicit changes may be performed are both missing and necessary, because such changes could potentially change the equivalence of keys that is measured by the hasher and key_equal.

I suggest to fix the unconditional wording involved with "immutable keys" by at least adding a hint for the reader that users may perform such changes in an explicit manner and to perform similar wording changes as 103 did for the ordered associative containers also for the unordered containers.

[ 2010-03-27 Daniel provides wording. ]

This update attempts to provide normative wording that harmonizes the key and function object constraints of associative and unordered containers.

[ 2010 Batavia: ]

We're uncomfortable with the first agenda item, and we can live with the second agenda item being applied before or after Madrid.

Proposed resolution:

  1. Change 23.2.4 [associative.reqmts]/2 as indicated: [This ensures that associative containers make better clear what this "arbitrary" type is, as the unordered containers do in 23.2.5 [unord.req]/3]

    2 Each associative container is parameterized on Key and an ordering relation Compare that induces a strict weak ordering (25.4) on elements of Key. In addition, map and multimap associate an arbitrary mapped typetype T with the Key. The object of type Compare is called the comparison object of a container.

  2. Change 23.2.4 [associative.reqmts]/5 as indicated: [This removes the too strong requirement that keys must not be changed at all and brings this line in sync with 23.2.5 [unord.req]/7. We take care about the real constraints by the remaining suggested changes. The rationale provided by LWG 103 didn't really argue why that addition is necessary, and I believe the remaining additions make it clear that any user changes have strong restrictions]:

    5 For set and multiset the value type is the same as the key type. For map and multimap it is equal to pair<const Key, T>. Keys in an associative container are immutable.

  3. Change 23.2.5 [unord.req]/3+4 as indicated: [The current sentence of p.4 has doesn't say something really new and this whole subclause misses to define the concepts of the container-specific hasher object and predicate object. We introduce the term key equality predicate which is already used in the requirements table. This change does not really correct part of this issue, but is recommended to better clarify the nomenclature and the difference between the function objects and the function object types, which is important, because both can potentially be stateful.]

    3 Each unordered associative container is parameterized by Key, by a function object type Hash that meets the Hash requirements (20.2.4) and acts as a hash function for argument values of type Key, and by a binary predicate Pred that induces an equivalence relation on values of type Key. Additionally, unordered_map and unordered_multimap associate an arbitrary mapped type T with the Key.

    4 The container's object of type Hash - denoted by hash - is called the hash function of the container. The container's object of type Pred - denoted by pred - is called the key equality predicate of the container.A hash function is a function object that takes a single argument of type Key and returns a value of type std::size_t.

  4. Change 23.2.5 [unord.req]/5 as indicated: [This adds a similar safe-guard as the last sentence of 23.2.4 [associative.reqmts]/3]

    5 Two values k1 and k2 of type Key are considered equivalent if the container's key equality predicatekey_equal function object returns true when passed those values. If k1 and k2 are equivalent, the container's hash function shall return the same value for both. [Note: thus, when an unordered associative container is instantiated with a non-default Pred parameter it usually needs a non-default Hash parameter as well. — end note] For any two keys k1 and k2 in the same container, calling pred(k1, k2) shall always return the same value. For any key k in a container, calling hash(k) shall always return the same value.

  5. After 23.2.5 [unord.req]/7 add the following new paragraph: [This ensures the same level of compile-time protection that we already require for associative containers. It is necessary for similar reasons, because any change in the stored key which would change it's equality relation to others or would change it's hash value such that it would no longer fall in the same bucket, would break the container invariants]

    7 For unordered_set and unordered_multiset the value type is the same as the key type. For unordered_map and unordered_multimap it is std::pair<const Key, T>.

    For unordered containers where the value type is the same as the key type, both iterator and const_iterator are constant iterators. It is unspecified whether or not iterator and const_iterator are the same type. [Note: iterator and const_iterator have identical semantics in this case, and iterator is convertible to const_iterator. Users can avoid violating the One Definition Rule by always using const_iterator in their function parameter lists. — end note]

1215. list::merge with unequal allocators

Section: 23.3.5.5 [list.ops] Status: Tentatively Voting Submitter: Pablo Halpern Opened: 2009-09-24 Last modified: 2011-03-24

View all other issues in [list.ops].

View all issues with Tentatively Voting status.

Discussion:

In Bellevue (I think), we passed N2525, which, among other things, specifies that the behavior of list::splice is undefined if the allocators of the two lists being spliced do not compare equal. The same rationale should apply to list::merge. The intent of list::merge (AFAIK) is to move nodes from one sorted list into another sorted list without copying the elements. This is possible only if the allocators compare equal.

Proposed resolution:

Relative to the August 2009 WP, N2857, change 23.3.5.5 [list.ops], paragraphs 22-25 as follows: 

void merge(list&& x);
template <class Compare> void merge(list&& x, Compare comp);

Requires: both the list and the argument list shall be sorted according to operator< or comp.

Effects: If (&x == this) does nothing; otherwise, merges the two sorted ranges [begin(), end()) and [x.begin(), x.end()). The result is a range in which the elements will be sorted in non-decreasing order according to the ordering defined by comp; that is, for every iterator i, in the range other than the first, the condition comp(*i, *(i - 1)) will be false.

Remarks: Stable. If (&x != this) the range [x.begin(), x.end()) is empty after the merge. No elements are copied by this operation. The behavior is undefined if this->get_allocator() != x.get_allocator().

Complexity: At most size() + x.size() - 1 applications of comp if (&x != this); otherwise, no applications of comp are performed. If an exception is thrown other than by a comparison there are no effects.

1252. wbuffer_convert::state_type inconsistency

Section: 22.3.3.2.3 [conversions.buffer] Status: Immediate Submitter: Bo Persson Opened: 2009-10-21 Last modified: 2011-03-24

View all issues with Immediate status.

Discussion:

The synopsis for wbuffer_convert 22.3.3.2.3 [conversions.buffer]/2 contains 

typedef typename Tr::state_type   state_type;

making state_type a synonym for (possibly) some char_traits<x>::state_type.

However, in paragraph 9 of the same section, we have 

typedef typename Codecvt::state_type state_type;

The type shall be a synonym for Codecvt::state_type.

From what I can see, it might be hard to implement wbuffer_convert if the types were not both std::mbstate_t, but I cannot find a requirement that they must be the same type.

[ Batavia 2010: ]

Howard to draft wording, move to Review. Run it by Bill. Need to move this in Madrid.

[2011-03-06: Howard drafts wording]

[2011-03-24 Madrid meeting]

Moved to Immediate

Proposed resolution:

Modify the state_type typedef in the synopsis of 22.3.3.2.3 [conversions.buffer] p.2 as shown [This makes the synopsis consistent with 22.3.3.2.3 [conversions.buffer] p.9]:

namespace std {
template<class Codecvt,
  class Elem = wchar_t,
  class Tr = std::char_traits<Elem> >
class wbuffer_convert
  : public std::basic_streambuf<Elem, Tr> {
public:
  typedef typename TrCodecvt::state_type state_type;
  […]
};
}

1253. invalidation of iterators and emplace vs. insert inconsistence in assoc. containers

Section: 23.2.4 [associative.reqmts] Status: Tentatively Voting Submitter: Boris Dušek Opened: 2009-10-24 Last modified: 2011-03-24

View other active issues in [associative.reqmts].

View all other issues in [associative.reqmts].

View all issues with Tentatively Voting status.

Discussion:

In the latest published draft N2960, section 23.2.4 [associative.reqmts], paragraph 8, it is specified that that insert does not invalidate any iterators. As per 23.2.1 [container.requirements.general], paragraph 12, this holds true not only for insert, but emplace as well. This gives the insert member a special treatment w.r.t. emplace member in 23.2.4 [associative.reqmts], par. 8, since both modify the container. For the sake of consistency, in 23.2.4 [associative.reqmts], par. 8: either reference to insert should be removed (i.e. count on 23.2.1 [container.requirements.general], par. 12), or reference to emplace be added (i.e. mention all members of assoc. containers that modify it).

[ 2009-11-18 Chris provided wording. ]

This suggested wording covers both the issue discussed, and a number of other identical issues (namely insert being discussed without emplace). I'm happy to go back and split and introduce a new issue if appropriate, but I think the changes are fairly mechanical and obvious.

[ 2010-01-23 Daniel Krügler and J. Daniel García updated wording to make the use of hint consistent with insert. ]

[ 2011-02-23 Daniel Krügler adapts wording to numbering changes to match the N3225 draft. During this action it was found that 23.2.5 [unord.req] had been changed considerably due to acceptance of N3068 during the Pittsburgh meeting, such that the suggested wording change to p. 6 can no longer be applied. The new wording is more general and should now include insert() and emplace() calls as well ("mutating operations"). ]

[2011-03-06 Daniel Krügler adapts wording to numbering changes to match the N3242 draft]

Proposed resolution:

  1. Modify bullet 1 of 23.2.1 [container.requirements.general], p. 10:

    10 Unless otherwise specified (see [associative.reqmts.except], [unord.req.except], [deque.modifiers], and [vector.modifiers]) all container types defined in this Clause meet the following additional requirements:

  2. Modify 23.2.4 [associative.reqmts], p. 4:

    4 An associative container supports unique keys if it may contain at most one element for each key. Otherwise, it supports equivalent keys. The set and map classes support unique keys; the multiset and multimap classes support equivalent keys. For multiset and multimap, insert, emplace, and erase preserve the relative ordering of equivalent elements.

  3. Modify Table 102 — Associative container requirements in 23.2.4 [associative.reqmts]:

    Table 102 — Associative container requirements (in addition to container)
    Expression Return type Assertion/note
    pre-/post-condition    		 Complexity
    […]
    a_eq.emplace(args) iterator […] Effects: Inserts a T object t constructed with std::forward<Args>(args)... and returns the iterator pointing to the newly inserted element. If a range containing elements equivalent to t exists in a_eq, t is inserted at the end of that range. logarithmic
    a.emplace_hint(p, args) iterator equivalent to a.emplace(std::forward<Args>(args)...). Return value is an iterator pointing to the element with the key equivalent to the newly inserted element. The const_iterator p is a hint pointing to where the search should start. The element is inserted as close as possible to the position just prior to p. Implementations are permitted to ignore the hint. logarithmic in general, but amortized constant if the element is inserted right after before p
    […]

  4. Modify 23.2.4 [associative.reqmts], p. 9:

    9 The insert and emplace members shall not affect the validity of iterators and references to the container, and the erase members shall invalidate only iterators and references to the erased elements.

  5. Modify 23.2.4.1 [associative.reqmts.except], p. 2:

    2 For associative containers, if an exception is thrown by any operation from within an insert() or emplace() function inserting a single element, the insert() function insertion has no effect.

  6. Modify 23.2.5 [unord.req], p. 13 and p. 14:

    6 An unordered associative container supports unique keys if it may contain at most one element for each key. Otherwise, it supports equivalent keys. unordered_set and unordered_map support unique keys. unordered_multiset and unordered_multimap support equivalent keys. In containers that support equivalent keys, elements with equivalent keys are adjacent to each other in the iteration order of the container. Thus, although the absolute order of elements in an unordered container is not specified, its elements are grouped into equivalent-key groups such that all elements of each group have equivalent keys. Mutating operations on unordered containers shall preserve the relative order of elements within each equivalent-key group unless otherwise specified.

    […]

    13 The insert and emplace members shall not affect the validity of references to container elements, but may invalidate all iterators to the container. The erase members shall invalidate only iterators and references to the erased elements.

    14 The insert and emplace members shall not affect the validity of iterators if (N+n) < z * B, where N is the number of elements in the container prior to the insert operation, n is the number of elements inserted, B is the container's bucket count, and z is the container's maximum load factor.

  7. Modify 23.2.5.1 [unord.req.except], p. 2:

    2 For unordered associative containers, if an exception is thrown by any operation other than the container's hash function from within an insert() or emplace() function inserting a single element, the insert() insertion function has no effect.

1279. forbid [u|bi]nary_function specialization

Section: D.10.1 [depr.base] Status: Immediate Submitter: Alberto Ganesh Barbati Opened: 2009-11-30 Last modified: 2011-03-25

View all issues with Immediate status.

Discussion:

A program should not be allowed to add specialization of class templates unary_function and binary_function, in force of 17.6.4.2.1 [namespace.std]/1. If a program were allowed to specialize these templates, the library could no longer rely on them to provide the intended typedefs or there might be other undesired interactions.

[ 2010-03-27 Daniel adds: ]

Accepting issue 1290 would resolve this issue as NAD editorial.

[ 2010-10-24 Daniel adds: ]

Accepting n3145 would resolve this issue as NAD editorial.

[ 2010 Batavia: ]

Pete: Is this issue actually addressed by N3198, or did deprecating unary/binary_function?

We determined that this issue is NOT resolved and that it must be resolved or else N3198 could break code that does specialize unary⁄binary function.

Matt: don't move to NAD

Howard: I suggest we go further and move 1279 to ready for Madrid.

Group: Agrees move 1279 to ready for Madrid

Previous proposed resolution:

1 The following classes class templates are provided to simplify the typedefs of the argument and result types:. A program shall not declare specializations of these templates.

[2011-03-06 Daniel comments]

This meeting outcome was not properly reflected in the proposed resolution. I also adapted the suggested wording to the N3242 numbering and content state. During this course of action it turned out that the first suggested wording change has already been applied.

Proposed resolution:

Change paragraph D.10.1 [depr.base]/1 as follows:

1 The class templates unary_function and binary_function are deprecated. A program shall not declare specializations of these templates.

1310. forward_list splice_after from lvalues

Section: 23.3.4.6 [forwardlist.ops] Status: Tentatively Voting Submitter: Howard Hinnant Opened: 2010-02-05 Last modified: 2011-03-24

View all other issues in [forwardlist.ops].

View all issues with Tentatively Voting status.

Discussion:

We've moved 1133 to Tentatively Ready and I'm fine with that.

1133 adds lvalue-references to the splice signatures for list. So now list can splice from lvalue and rvalue lists (which was the intent of the original move papers btw). During the discussion of this issue it was mentioned that if we want to give the same treatment to forward_list, that should be a separate issue.

This is that separate issue.

Consider the following case where you want to splice elements from one place in a forward_list to another. Currently this must be coded like so: 

fl.splice_after(to_here, std::move(fl), from1, from2);

This looks pretty shocking to me. I would expect to be able to code instead: 

fl.splice_after(to_here, fl, from1, from2);

but we currently don't allow it.

When I say move(fl), I consider that as saying that I don't care about the value of fl any more (until I assign it a new value). But in the above example, this simply isn't true. I do care about the value of fl after the move, and I'm not assigning it a new value. I'm merely permuting its current value.

I propose adding forward_list& overloads to the 3 splice_after members. For consistency's sake (principal of least surprise) I'm also proposing to overload merge this way as well.

Proposed resolution:

Add to the synopsis of 23.3.4.1 [forwardlist.overview]: 

template <class T, class Allocator = allocator<T> >
class forward_list {
public:
  ...
  // [forwardlist.ops], forward_list operations:
  void splice_after(const_iterator p, forward_list& x);
  void splice_after(const_iterator p, forward_list&& x);
  void splice_after(const_iterator p, forward_list& x, const_iterator i);
  void splice_after(const_iterator p, forward_list&& x, const_iterator i);
  void splice_after(const_iterator p, forward_list& x,
                    const_iterator first, const_iterator last);
  void splice_after(const_iterator p, forward_list&& x,
                    const_iterator first, const_iterator last);
  ...
  void merge(forward_list& x);
  void merge(forward_list&& x);
  template <class Compare> void merge(forward_list& x, Compare comp);
  template <class Compare> void merge(forward_list&& x, Compare comp);
  ...
};

Add to the signatures of 23.3.4.6 [forwardlist.ops]: 

void splice_after(const_iterator p, forward_list& x);
void splice_after(const_iterator p, forward_list&& x);

1 ...

void splice_after(const_iterator p, forward_list& x, const_iterator i);
void splice_after(const_iterator p, forward_list&& x, const_iterator i);

4 ...

void splice_after(const_iterator p, forward_list& x,
                const_iterator first, const_iterator last);
void splice_after(const_iterator p, forward_list&& x,
                const_iterator first, const_iterator last);

7 ...

void merge(forward_list& x);
void merge(forward_list&& x);
template <class Compare> void merge(forward_list& x, Compare comp);
template <class Compare> void merge(forward_list&& x, Compare comp);

16 ...

1320. Header for iter_swap

Section: 24.3 [iterator.synopsis] Status: Tentatively NAD Future Submitter: Alisdair Meredith Opened: 2010-02-16 Last modified: 2011-03-24

Discussion:

The iter_swap function template appears in the <algorithm> header, yet its main use is in building further algorithms, not calling existing ones. The main clients are implementers of data structures and their iterators, so it seems most appropriate to place the template in the <iterator> header instead.

Note that this is not an issue for implementers of the standard library, as they rarely use the standard headers directly, designing a more fine-grained set of headers for their own internal use. This option is not available to customers of the standard library.

Note that we cannot remove iter_swap from <algorithm> without breaking code, but there is no reason we cannot offer the same declaration via two standard headers. Alternatively, require <algorithm> to #include <iterator>, but introducing the dependency on the iterator adaptors seems un-necessary.

[ ]

Discussed possibly moving to <utility> but don't like that. Some not seeing this as a defect, and want to keep it in <algorithm>. No one seems to feel strongly about moving to <iterator>.

Proposed resolution:

Add the declaration of iter_swap to the <iterator> header synopsis (24.3 [iterator.synopsis]), with a note that it is documented in clause 25 [algorithms]. 

...
template <class T, size_t N> T* end(T (&array)[N]);

// documented in 25 [algorithms]
template<class ForwardIterator1, class ForwardIterator2>
  void iter_swap(ForwardIterator1 a, ForwardIterator2 b);

1330. Move container requirements into requirements tables

Section: 23.2 [container.requirements] Status: Deferred Submitter: Nicolai Josuttis Opened: 2010-03-10 Last modified: 2011-03-24

View all other issues in [container.requirements].

View all issues with Deferred status.

Discussion:

Abstract:

In general, it seems that in a couple of places container behavior is not described in requirement tables although it is a general behavior.

History:

Issue 676 added move semantics to unordered containers. For the added insert functions the Editor requested to put their semantic description into a requirements table rather than describing them for each container individually. The text however was taken from the associative containers, where we also have the semantics for each container described. Also, 1034 is to some extend requesting a clarification of the requirement tables and it turned out that in other places we have the same problem (e.g. we have no general requirement for type pointer and const_pointer although each container has them with issue 1306).

From my personal list of functions in requirement tables and containers, the following types/functions are missing in requirement tables:

As a special case, we lack the following requirements for all sequence containers BUT array (so special wording or a new container category is required):

Note that we also might have to add additional requirements on other places for sequence containers because having an allocator requires additional statements for the treatment of the allocators. E.g. swap for containers with allocators is not specified in any requirement table.

And finally, if we have the requirements in the requirements tables, we can remove the corresponding descriptions for the individual container. However, note that sequence container requirements have NO complexity column, so that we still need container specific descriptions for the functions listed there.

[ 2010 Batavia ]

While there is consensus that further cleaning up the container requirement tables would be a good thing, there is no feeling that this must be done in time for 0x. The issue remains open, but Deferred.

Proposed resolution:

1332. Let Hash objects throw!

Section: 17.6.3.4 [hash.requirements] Status: Voting Submitter: Daniel Krügler Opened: 2010-03-26 Last modified: 2011-03-24

View all issues with Voting status.

Discussion:

The currently added Hash requirements demand in Table 40 — Hash requirements [hash]:

Table 40 — Hash requirements [hash]
Expression Return type Requirement
h(k) size_t Shall not throw exceptions. [..]

While it surely is a generally accepted idea that hash function objects should not throw exceptions, this basic constraint for such a fundamental requirement set does neither match the current library policy nor real world cases:

  1. There are little known situations where a swap or move operation may throw an exception and in some popular domains such functions are required not to throw. But the library invested already efforts for good reasons to require "working" container implementations in the presence of throwing move or swap operations, see e.g. 23.2.4.1 [associative.reqmts.except], 23.2.5.1 [unord.req.except].
  2. The container library is already specified to cope with potentially throwing comparers, predicates, and hash function objects, see above.

  3. The new definition goes beyond the original hash requirements as specified by SGI library in regard to the exception requirement:

    http://www.sgi.com/tech/stl/HashFunction.html

  4. There are indeed real-world examples of potentially throwing hash functions, typically when the proxy pattern is used and when the to-be hashed proxied instance is some volatile object, e.g. a file or internet resource, that might suddenly be unavailable at the time of hashing.
  5. With the new noexcept language facility libraries can still take advantage of no-throw guarantees of hasher functions with stricter guarantees.

Even though the majority of all known move, swap, and hash functions won't throw and in some cases must not throw, it seems like unnecessary over-constraining the definition of a Hash functor not to propagate exceptions in any case and it contradicts the general principle of C++ to impose such a requirement for this kind of fundamental requirement.

[ 2010-11-11 Daniel asks the working group whether they would prefer a replacement for the second bullet of the proposed resolution (a result of discussing this with Alberto) of the form: ]

Add to 20.8.12 [unord.hash]/1 a new bullet:

1 The unordered associative containers defined in Clause 23.5 use specializations of the class template hash as the default hash function. For all object types Key for which there exists a specialization hash<Key>, the instantiation hash<Key> shall:

[Batavia: Closed as NAD Future, then reopened. See the wiki for Tuesday.]

Proposed resolution:

  1. Change Table 26 — Hash requirements [tab:hash] as indicated:

    Table 26 — Hash requirements [tab:hash]
    Expression Return type Requirement
    h(k) size_t Shall not throw exceptions. […]

  2. Add to 20.8.12 [unord.hash] p. 1 a new bullet:

    1 The unordered associative containers defined in Clause 23.5 [unord] use specializations of the class template hash as the default hash function. For all object types Key for which there exists a specialization hash<Key>, the instantiation hash<Key> shall:

    • satisfy the Hash requirements ([hash.requirements]), with Key as the function call argument type, the DefaultConstructible requirements (Table [defaultconstructible]), the CopyAssignable requirements (Table [copyassignable]),
    • be swappable ([swappable.requirements]) for lvalues,
    • provide two nested types result_type and argument_type which shall be synonyms for size_t and Key, respectively,
    • satisfy the requirement that if k1 == k2 is true, h(k1) == h(k2) is also true, where h is an object of type hash<Key> and k1 and k2 are objects of type Key,.
    • satisfy the requirement that the expression h(k), where h is an object of type hash<Key> and k is an object of type Key, shall not throw an exception, unless hash<Key> is a user-defined specialization that depends on at least one user-defined type.

1349. [FCD] swap should not throw

Section: 17 [library] Status: Immediate Submitter: BSI Opened: 2010-08-25 Last modified: 2011-03-24

View all other issues in [library].

View all issues with Immediate status.

Discussion:

Addresses GB-65

Nothrowing swap operations are key to many C++ idioms, notably the common copy/swap idiom to provide the strong exception safety guarantee.

[ Resolution proposed by ballot comment ]

Where possible, all library types should provide a swap operation with an exception specification guaranteeing no exception shall propagate. Where noexcept(true) cannot be guaranteed to not terminate the program, and the swap in questions is a template, an exception specification with the appropriate conditional expression could be specified.

[2011-03-13: Daniel comments and drafts wording]

During a survey of the library some main categories for potential noexcept swap function could be isolated:

  1. Free swap functions that are specified in terms of already noexcept swap member functions, like that of valarray.
  2. Free swap of std::function, and member and free swap functions of stream buffers and streams where considered but rejected as good candidates, because of the danger to potentially impose requirements of existing implementations. These functions could be reconsidered as candidates in the future.

Negative list:

  1. Algorithms related to swap, like iter_swap, have not been touched, because there are no fundamental exceptions constraints on iterator operations in general (only for specific types, like library container iterators)

While evaluating the current state of swap functions of library components it was observed that several conditional noexcept functions have turned into unconditional ones, e.g. in the header <utility> synopsis:

template<class T> void swap(T& a, T& b) noexcept;

The suggested resolution shown below also attempts to fix these cases.

[2011-03-22 Daniel redrafts to satisfy new criteria for applying noexcept. Parts resolved by N3263-v2 and D3267 are not added here.]

Proposed resolution:

  1. Edit 20.2 [utility] p. 2, header <utility> synopsis and 20.2.2 [utility.swap] before p. 1, as indicated (The intent is to fix an editorial omission):

    template<class T> void swap(T& a, T& b) noexcept(see below);

  2. Edit the prototype declaration in 20.3.2 [pairs.pair] before p. 34 as indicated (The intent is to fix an editorial omission):

    void swap(pair& p) noexcept(see below);

  3. Edit 20.4.1 [tuple.general] p. 2 header <tuple> synopsis and 20.4.2.9 [tuple.special] before p. 1 as indicated (The intent is to fix an editorial omission):

    template <class... Types>
void swap(tuple<Types...>& x, tuple<Types...>& y) noexcept(see below);

  4. Edit 20.4.2 [tuple.tuple], class template tuple synopsis and 20.4.2.3 [tuple.swap] before p. 1 as indicated (The intent is to fix an editorial omission):

    void swap(tuple&) noexcept(see below);

  5. Edit 20.6.2 [memory.syn] p. 1, header <memory> synopsis as indicated (The intent is to fix an editorial omission of the proposing paper N3195).

    template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b) noexcept;

  6. Edit header <valarray> synopsis, 26.6.1 [valarray.syn] and 26.6.3.4 [valarray.special] before p. 1 as indicated [Drafting comment: The corresponding member swap is already noexcept]:

    template<class T> void swap(valarray<T>&, valarray<T>&) noexcept;

1371. [FCD] standard exceptions require stronger no-throw guarantees

Section: 19 [diagnostics] Status: Tentatively NAD Submitter: BSI Opened: 2010-08-25 Last modified: 2011-03-24

View all issues with Tentatively NAD status.

Discussion:

Addresses GB-75

None of the exception types defined in clause 19 are allowed to throw an exception on copy or move operations, but there is no clear specification that the operations have an exception specification to prove it. Note that the implicitly declared constructors, taking the exception specification from their base class (ultimately std::exception) will implicitly generate a noexcept exception specification if all of their data members similarly declare noexcept operations. As the representation is unspecified, we cannot assume nonthrowing operations unless we explicitly state this as a constraint on the implementation.

[ Resolution proposed by ballot comment: ]

Add a global guarantee that all exception types defined in clause 19 that rely on implicitly declared operations have a non-throwing exception specification on those operations.

[ 2010 Batavia: ]

This is addressed by the current words in 18.8.1 [exception], p2

Each standard library class T that derives from class exception shall have a publicly accessible copy constructor and a publicly accessible copy assignment operator that do not exit with an exception.

Proposed resolution:

1374. [FCD] Clarify moved-from objects are "toxic"

Section: 17.6.3.1 [utility.arg.requirements] Status: Tentatively NAD Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-03-24

View all other issues in [utility.arg.requirements].

View all issues with Tentatively NAD status.

Discussion:

Addresses US-85

20.2.1 Table 34 "MoveConstructible requirements" says "Note: rv remains a valid object. Its state is unspecified". Some components give stronger guarantees. For example, moved-from shared_ptrs are guaranteed empty (20.9.11.2.1/25). In general, what the standard really should say (preferably as a global blanket statement) is that moved-from objects can be destroyed and can be the destination of an assignment. Anything else is radioactive. For example, containers can be "emptier than empty". This needs to be explicit and required generally.

Note: The last time that one of us mentioned "emptier than empty" (i.e. containers missing sentinel nodes, etc.) the objection was that containers can store sentinel nodes inside themselves in order to avoid dynamically allocating them. This is unacceptable because

(a) it forces existing implementations (i.e. Dinkumware's, Microsoft's, IBM's, etc.) to change for no good reason (i.e. permitting more operations on moved-from objects), and

(b) it invalidates end-iterators when swapping containers. (The Working Paper currently permits end-iterator invalidation, which we consider to be wrong, but that's a separate argument. In any event, mandating end-iterator invalidation is very different from permitting it.)

[ Resolution proposed in ballot comment ]

State as a general requirement that moved-from objects can be destroyed and can be the destination of an assignment. Any other use is undefined behavior.

Proposed resolution:

Resolved by N3241

1385. [FCD] tuple_cat should be a single variadic signature

Section: 20.4.2.4 [tuple.creation] Status: Voting Submitter: BSI Opened: 2010-08-25 Last modified: 2011-03-24

View all other issues in [tuple.creation].

View all issues with Voting status.

Discussion:

Addresses GB-88

The tuple_cat template consists of four overloads and that can concatenate only two tuples. A single variadic signature that can concatenate an arbitrary number of tuples would be preferred.

[ Resolution proposed by ballot comment: ]

Adopt a simplified form of the proposal in n2975, restricted to tuples and neither requiring nor outlawing support for other tuple-like types.

[ 2010 Rapperswil: Alisdair to provide wording. ]

[ 2010-11-06: Daniel comments and proposes some alternative wording: ]

There are some problems in the wording: First, even though the result type tuple<see below> implies it, the specification of the contained tuple element types is missing. Second, the term "tuple protocol" is not defined anywhere and I see no reason why this normative wording should not be a non-normative note. We could at least give a better approximation, maybe "tuple-like protocol" as indicated from header <utility> synopsis. Further, it seems to me that the effects need to contain a combination of std::forward with the call of get. Finally I suggest to replace the requirements Move/CopyConstructible by proper usage of is_constructible, as indicated by n3140.

[ 2010 Batavia ]

Moved to Ready with Daniel's improved wording.

Proposed resolution:

Note: This alternate proposed resolution works only if 1191 has been accepted.

  1. Change 20.4.1 [tuple.general] p. 2, header <tuple> synopsis, as indicated: 
    namespace std {

...

// 20.4.2.4, tuple creation functions:
const unspecified ignore;

template <class... Types>
  tuple<VTypes...> make_tuple(Types&&...);
  template <class... Types>
  tuple<ATypes...> forward_as_tuple(Types&&...);
  
template<class... Types>
  tuple<Types&...> tie(Types&...);
  
template <class... TTypes, class... UTypes>
  tuple<TTypes..., UTypes...> tuple_cat(const tuple<TTypes...>&, const tuple<UTypes...>&);
template <class... TTypes, class... UTypes>
  tuple<TTypes..., UTypes...> tuple_cat(tuple<TTypes...>&&, const tuple<UTypes...>&);
template <class... TTypes, class... UTypes>
  tuple<TTypes..., UTypes...> tuple_cat(const tuple<TTypes...>&, tuple<UTypes...>&&);
template <class... TTypes, class... UTypes>
  tuple<TTypes..., UTypes...> tuple_cat(tuple<TTypes...>&&, tuple<UTypes...>&&);
template <class... Tuples>
  tuple<CTypes...> tuple_cat(Tuples&&...);

...
  2. Change 20.4.2.4 [tuple.creation] as indicated: 
    template <class... TTypes, class... UTypes>
  tuple<TTypes..., UTypes...> tuple_cat(const tuple<TTypes...>& t, const tuple<UTypes...>& u);

    8 Requires: All the types in TTypes shall be CopyConstructible (Table 35). All the types in UTypes shall be CopyConstructible (Table 35).

    9 Returns: A tuple object constructed by copy constructing its first sizeof...(TTypes) elements from the corresponding elements of t and copy constructing its last sizeof...(UTypes) elements from the corresponding elements of u. 

    template <class... TTypes, class... UTypes>
  tuple<TTypes..., UTypes...> tuple_cat(tuple<TTypes...>&& t, const tuple<UTypes...>& u);

    10 Requires: All the types in TTypes shall be MoveConstructible (Table 34). All the types in UTypes shall be CopyConstructible (Table 35).

    11 Returns: A tuple object constructed by move constructing its first sizeof...(TTypes) elements from the corresponding elements of t and copy constructing its last sizeof...(UTypes) elements from the corresponding elements of u. 

    template <class... TTypes, class... UTypes>
  tuple<TTypes..., UTypes...> tuple_cat(const tuple<TTypes...>& t, tuple<UTypes...>&& u);

    12 Requires: All the types in TTypes shall be CopyConstructible (Table 35). All the types in UTypes shall be MoveConstructible (Table 34).

    13 Returns: A tuple object constructed by copy constructing its first sizeof...(TTypes) elements from the corresponding elements of t and move constructing its last sizeof...(UTypes) elements from the corresponding elements of u. 

    template <class... TTypes, class... UTypes>
  tuple<TTypes..., UTypes...> tuple_cat(tuple<TTypes...>&& t, tuple<UTypes...>&& u);

    14 Requires: All the types in TTypes shall be MoveConstructible (Table 34). All the types in UTypes shall be MoveConstructible (Table 34).

    15 Returns: A tuple object constructed by move constructing its first sizeof...(TTypes) elements from the corresponding elements of t and move constructing its last sizeof...(UTypes) elements from the corresponding elements of u. 

    template <class... Tuples>
  tuple<CTypes...> tuple_cat(Tuples&&... tpls);

    8 Let Ti be the ith type in Tuples, Ui be remove_reference<Ti>::type, and tpi be the ith parameter in the function parameter pack tpls, where all indexing is zero-based in the following paragraphs of this sub-clause [tuple.creation].

    9 Requires: For all i, Ui shall be the type cvi tuple<Argsi...>, where cvi is the (possibly empty) ith cv-qualifier-seq, and Argsi is the parameter pack representing the element types in Ui. Let Aik be the kith type in Argsi, then for all Aik the following requirements shall be satisfied: If Ti is deduced as an lvalue reference type, then is_constructible<Aik, cvi Aik&>::value == true, otherwise is_constructible<Aik, cvi Aik&&>::value == true.

    10 Remarks: The types in CTypes shall be equal to the ordered sequence of the expanded types Args0..., Args1..., Argsn-1..., where n equals sizeof...(Tuples). Let ei... be the ith ordered sequence of tuple elements of the result tuple object corresponding to the type sequence Argsi.

    11 Returns: A tuple object constructed by initializing the kith type element eik in ei... with get<ki>(std::forward<Ti>(tpi)) for each valid ki and each element group ei in order.

    12 [Note: An implementation may support additional types in the parameter pack Tuples, such as pair and array that support the tuple-like protocol. — end note]

1401. [FCD] unique_ptr<T> == nullptr

Section: 20.6 [memory] Status: Immediate Submitter: BSI Opened: 2010-08-25 Last modified: 2011-03-24

View all other issues in [memory].

View all issues with Immediate status.

Discussion:

Addresses GB-99

One reason that the unique_ptr constructor taking a nullptr_t argument is not explicit is to allow conversion of nullptr to unique_ptr in contexts like equality comparison. Unfortunately operator== for unique_ptr is a little more clever than that, deducing template parameters for both arguments. This means that nullptr does not get deduced as unique_ptr type, and there are no other comparison functions to match.

[ Resolution proposed by ballot comment: ]

Add the following signatures to 20.6 [memory] p.1, <memory> header synopsis: 

template<typename T, typename D>
bool operator==(const unique_ptr<T, D> & lhs, nullptr_t);
template<typename T, typename D>
bool operator==(nullptr_t, const unique_ptr<T, D> & rhs);
template<typename T, typename D>
bool operator!=(const unique_ptr<T, D> & lhs, nullptr_t);
template<typename T, typename D>
bool operator!=(nullptr_t, const unique_ptr<T, D> & rhs);

[ 2010-11-02 Daniel comments and provides a proposed resolution: ]

The same problem applies to shared_ptr as well: In both cases there are no conversions considered because the comparison functions are templates. I agree with the direction of the proposed resolution, but I believe it would be very surprising and inconsistent, if given a smart pointer object p, the expression p == nullptr would be provided, but not p < nullptr and the other relational operators. According to 5.9 [expr.rel] they are defined if null pointer values meet other pointer values, even though the result is unspecified for all except some trivial ones. But null pointer values are nothing special here: The Library already defines the relational operators for both unique_ptr and shared_ptr and the outcome of comparing non-null pointer values will be equally unspecified. If the idea of supporting nullptr_t arguments for relational operators is not what the committee prefers, I suggest at least to consider to remove the existing relational operators for both unique_ptr and shared_ptr for consistency. But that would not be my preferred resolution of this issue.

The number of overloads triple the current number, but I think it is much clearer to provide them explicitly instead of adding wording that attempts to say that "sufficient overloads" are provided. The following proposal makes the declarations explicit.

Additionally, the proposal adds the missing declarations for some shared_ptr comparison functions for consistency.

[ 2010-11-03 Daniel adds: ]

Issue 1297 is remotely related. The following proposed resolution splits this bullet into sub-bullets A and B. Sub-bullet A would also solve 1297, but sub-bullet B would not.

A further remark in regard to the proposed semantics of the ordering of nullptr against other pointer(-like) values: One might think that the following definition might be superior because of simplicity: 

template<class T>
bool operator<(const shared_ptr<T>& a, nullptr_t);
template<class T>
bool operator>(nullptr_t, const shared_ptr<T>& a);

Returns: false.

The underlying idea behind this approach is the assumption that nullptr corresponds to the least ordinal pointer value. But this assertion does not hold for all supported architectures, therefore this approach was not followed because it would lead to the inconsistency, that the following assertion could fire: 

shared_ptr<int> p(new int);
shared_ptr<int> null;
bool v1 = p < nullptr;
bool v2 = p < null;
assert(v1 == v2);

[2011-03-06: Daniel comments]

The current issue state is not acceptable, because the Batavia meeting did not give advice whether choice A or B of bullet 3 should be applied. Option B will now be removed and if this resolution is accepted, issue 1297 should be declared as resolved by 1401. This update also resyncs the wording with N3242.

Proposed resolution:

Wording changes are against N3242.

  1. Change 20.6.2 [memory.syn] p. 1, header <memory> synopsis as indicated. noexcept specifications are only added, where the guarantee exists, that the function shall no throw an exception (as replacement of "Throws: Nothing". Note that the noexcept additions to the shared_ptr comparisons are editorial, because they are already part of the accepted paper n3195: 
    namespace std {
  […]
  // [unique.ptr] Class unique_ptr:
  template <class T> class default_delete;
  template <class T> class default_delete<T[]>;
  template <class T, class D = default_delete<T>> class unique_ptr;
  template <class T, class D> class unique_ptr<T[], D>;

  template <class T1, class D1, class T2, class D2>
  bool operator==(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);
  template <class T1, class D1, class T2, class D2>
  bool operator!=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);
  template <class T1, class D1, class T2, class D2>
  bool operator<(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);
  template <class T1, class D1, class T2, class D2>
  bool operator<=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);
  template <class T1, class D1, class T2, class D2>
  bool operator>(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);
  template <class T1, class D1, class T2, class D2>
  bool operator>=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);

  template <class T, class D>
  bool operator==(const unique_ptr<T, D>& x, nullptr_t) noexcept;
  template <class T, class D>
  bool operator==(nullptr_t, const unique_ptr<T, D>& x) noexcept;
  template <class T, class D>
  bool operator!=(const unique_ptr<T, D>& x, nullptr_t) noexcept;
  template <class T, class D>
  bool operator!=(nullptr_t, const unique_ptr<T, D>& x) noexcept;
  template <class T, class D>
  bool operator<(const unique_ptr<T, D>& x, nullptr_t);
  template <class T, class D>
  bool operator<(nullptr_t, const unique_ptr<T, D>& x);
  template <class T, class D>
  bool operator<=(const unique_ptr<T, D>& x, nullptr_t);
  template <class T, class D>
  bool operator<=(nullptr_t, const unique_ptr<T, D>& x);
  template <class T, class D>
  bool operator>(const unique_ptr<T, D>& x, nullptr_t);
  template <class T, class D>
  bool operator>(nullptr_t, const unique_ptr<T, D>& x);
  template <class T, class D>
  bool operator>=(const unique_ptr<T, D>& x, nullptr_t);
  template <class T, class D>
  bool operator>=(nullptr_t, const unique_ptr<T, D>& x);
  
  // [util.smartptr.weakptr], Class bad_weak_ptr:
  class bad_weak_ptr;

  // [util.smartptr.shared], Class template shared_ptr:
  template<class T> class shared_ptr;

  // [util.smartptr.shared.cmp], shared_ptr comparisons:
  template<class T, class U>
  bool operator==(shared_ptr<T> const& a, shared_ptr<U> const& b)  noexcept;
  template<class T, class U>
  bool operator!=(shared_ptr<T> const& a, shared_ptr<U> const& b)  noexcept;
  template<class T, class U>
  bool operator<(shared_ptr<T> const& a, shared_ptr<U> const& b)  noexcept;
  template<class T, class U>
  bool operator>(shared_ptr<T> const& a, shared_ptr<U> const& b)  noexcept;
  template<class T, class U>
  bool operator<=(shared_ptr<T> const& a, shared_ptr<U> const& b)  noexcept;
  template<class T, class U>
  bool operator>=(shared_ptr<T> const& a, shared_ptr<U> const& b)  noexcept;

  template<class T>
  bool operator==(shared_ptr<T> const& a, nullptr_t) noexcept;
  template<class T>
  bool operator==(nullptr_t, shared_ptr<T> const& a) noexcept;
  template<class T>
  bool operator!=(shared_ptr<T> const& a, nullptr_t) noexcept;
  template<class T>
  bool operator!=(nullptr_t, shared_ptr<T> const& a) noexcept;
  template<class T>
  bool operator<(shared_ptr<T> const& a, nullptr_t) noexcept;
  template<class T>
  bool operator<(nullptr_t, shared_ptr<T> const& a) noexcept;
  template>class T>
  bool operator>(shared_ptr<T> const& a, nullptr_t) noexcept;
  template>class T>
  bool operator>(nullptr_t, shared_ptr<T> const& a) noexcept;
  template<class T>
  bool operator<=(shared_ptr<T> const& a, nullptr_t) noexcept;
  template<class T>
  bool operator<=(nullptr_t, shared_ptr<T> const& a) noexcept;
  template>class T>
  bool operator>=(shared_ptr<T> const& a, nullptr_t) noexcept;
  template>class T>
  bool operator>=(nullptr_t, shared_ptr<T> const& a) noexcept;

  […]
}
  2. Change the synopsis just after 20.7.1 [unique.ptr] p. 6 as indicated: 
    namespace std {
  […]
  
  template <class T1, class D1, class T2, class D2>
  bool operator==(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);
  template <class T1, class D1, class T2, class D2>
  bool operator!=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);
  template <class T1, class D1, class T2, class D2>
  bool operator<(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);
  template <class T1, class D1, class T2, class D2>
  bool operator<=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);
  template <class T1, class D1, class T2, class D2>
  bool operator>(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);
  template <class T1, class D1, class T2, class D2>
  bool operator>=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);

  template <class T, class D>
  bool operator==(const unique_ptr<T, D>& x, nullptr_t) noexcept;
  template <class T, class D>
  bool operator==(nullptr_t, const unique_ptr<T, D>& x) noexcept;
  template <class T, class D>
  bool operator!=(const unique_ptr<T, D>& x, nullptr_t) noexcept;
  template <class T, class D>
  bool operator!=(nullptr_t, const unique_ptr<T, D>& x) noexcept;
  template <class T, class D>
  bool operator<(const unique_ptr<T, D>& x, nullptr_t);
  template <class T, class D>
  bool operator<(nullptr_t, const unique_ptr<T, D>& x);
  template <class T, class D>
  bool operator<=(const unique_ptr<T, D>& x, nullptr_t);
  template <class T, class D>
  bool operator<=(nullptr_t, const unique_ptr<T, D>& x);
  template <class T, class D>
  bool operator>(const unique_ptr<T, D>& x, nullptr_t);
  template <class T, class D>
  bool operator>(nullptr_t, const unique_ptr<T, D>& x);
  template <class T, class D>
  bool operator>=(const unique_ptr<T, D>& x, nullptr_t);
  template <class T, class D>
  bool operator>=(nullptr_t, const unique_ptr<T, D>& x);

}
  3. This bullet does now only suggest the first approach:

    Change 20.7.1.4 [unique.ptr.special] p. 4-7 as indicated and add a series of prototype descriptions:

    template <class T1, class D1, class T2, class D2>
  bool operator<(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);

    ? Requires: Let CT be common_type<unique_ptr<T1, D1>::pointer, unique_ptr<T2, D2>::pointer>::type. Then the specialization less<CT> shall be a function object type ([function.objects]) that induces a strict weak ordering ([alg.sorting]) on the pointer values.

    4 Returns: less<CT>()(x.get(), y.get())x.get() < y.get().

    ? Remarks: If unique_ptr<T1, D1>::pointer is not implicitly convertible to CT or unique_ptr<T2, D2>::pointer is not implicitly convertible to CT, the program is ill-formed. 

    template <class T1, class D1, class T2, class D2>
  bool operator<=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);

    5 Returns: !(y < x)x.get() <= y.get(). 

    template <class T1, class D1, class T2, class D2>
  bool operator>(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);

    6 Returns: (y < x)x.get() > y.get(). 

    template <class T1, class D1, class T2, class D2>
  bool operator>=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);

    7 Returns: !(x < y)x.get() >= y.get(). 

    template <class T, class D>
bool operator==(const unique_ptr<T, D>& x, nullptr_t) noexcept;
template <class T, class D>
bool operator==(nullptr_t, const unique_ptr<T, D>& x) noexcept;

    ? Returns: !x. 

    template <class T, class D>
bool operator!=(const unique_ptr<T, D>& x, nullptr_t) noexcept;
template <class T, class D>
bool operator!=(nullptr_t, const unique_ptr<T, D>& x) noexcept;

    ? Returns: (bool) x. 

    template <class T, class D>
bool operator<(const unique_ptr<T, D>& x, nullptr_t);
template <class T, class D>
bool operator>(nullptr_t, const unique_ptr<T, D>& x);

    ? Requires: The specialization less<unique_ptr<T, D>::pointer> shall be a function object type ([function.objects]) that induces a strict weak ordering ([alg.sorting]) on the pointer values.

    ? Returns: less<unique_ptr<T, D>::pointer>()(x.get(), nullptr). 

    template <class T, class D>
bool operator<(nullptr_t, const unique_ptr<T, D>& x);
template <class T, class D>
bool operator>(const unique_ptr<T, D>& x, nullptr_t);

    ? Requires: The specialization less<unique_ptr<T, D>::pointer> shall be a function object type ([function.objects]) that induces a strict weak ordering ([alg.sorting]) on the pointer values.

    ? Returns: less<unique_ptr<T, D>::pointer>()(nullptr, x.get()). 

    template <class T, class D>
bool operator<=(const unique_ptr<T, D>& x, nullptr_t);
template <class T, class D>
bool operator>=(nullptr_t, const unique_ptr<T, D>& x);

    ? Returns: !(nullptr < x). 

    template <class T, class D>
bool operator<=(nullptr_t, const unique_ptr<T, D>& x);
template <class T, class D>
bool operator>=(const unique_ptr<T, D>& x, nullptr_t);

    ? Returns: !(x < nullptr).

  4. Change 20.7.2.2 [util.smartptr.shared] p. 1, class template shared_ptr synopsis as indicated. For consistency reasons the remaining normal relation operators are added as well: 
    namespace std {

  […]

  // [util.smartptr.shared.cmp], shared_ptr comparisons:
  template<class T, class U>
  bool operator==(const shared_ptr<T>& a, const shared_ptr<U>& b) noexcept;
  template<class T, class U>
  bool operator!=(const shared_ptr<T>& a, const shared_ptr<U>& b) noexcept;
  template<class T, class U>
  bool operator<(const shared_ptr<T>& a, const shared_ptr<U>& b) noexcept;
  template<class T, class U>
  bool operator>(const shared_ptr<T>& a, const shared_ptr<U>& b) noexcept;
  template<class T, class U>
  bool operator<=(const shared_ptr<T>& a, const shared_ptr<U>& b) noexcept;
  template<class T, class U>
  bool operator>=(const shared_ptr<T>& a, const shared_ptr<U>& b) noexcept;

  template<class T>
  bool operator==(const shared_ptr<T>& a, nullptr_t) noexcept;
  template<class T>
  bool operator==(nullptr_t, const shared_ptr<T>& a) noexcept;
  template<class T>
  bool operator!=(const shared_ptr<T>& a, nullptr_t) noexcept;
  template<class T>
  bool operator!=(nullptr_t, const shared_ptr<T>& a) noexcept;
  template<class T>
  bool operator<(const shared_ptr<T>& a, nullptr_t) noexcept;
  template<class T>
  bool operator<(nullptr_t, const shared_ptr<T>& a) noexcept;
  template>class T>
  bool operator>(const shared_ptr<T>& a, nullptr_t) noexcept;
  template>class T>
  bool operator>(nullptr_t, const shared_ptr<T>& a) noexcept;
  template<class T>
  bool operator<=(const shared_ptr<T>& a, nullptr_t) noexcept;
  template<class T>
  bool operator<=(nullptr_t, const shared_ptr<T>& a) noexcept;
  template>class T>
  bool operator>=(const shared_ptr<T>& a, nullptr_t) noexcept;
  template>class T>
  bool operator>=(nullptr_t, const shared_ptr<T>& a) noexcept;

  […]
}
  5. Add the following series of prototype specifications at the very end of 20.7.2.2.7 [util.smartptr.shared.cmp]. For mixed comparison the general "generation" rule of 20.2.1 [operators] p. 10 does not apply, therefore all of them are defined. Below wording takes advantage of the simplified definition of the composite pointer type if one partner is a null pointer constant: 
    template<class T>
bool operator==(const shared_ptr<T>& a, nullptr_t) noexcept;
template<class T>
bool operator==(nullptr_t, const shared_ptr<T>& a) noexcept;

    ? Returns: !a. 

    template<class T>
bool operator!=(const shared_ptr<T>& a, nullptr_t) noexcept;
template<class T>
bool operator!=(nullptr_t, const shared_ptr<T>& a) noexcept;

    ? Returns: (bool) a. 

    template<class T>
bool operator<(const shared_ptr<T>& a, nullptr_t) noexcept;
template<class T>
bool operator>(nullptr_t, const shared_ptr<T>& a) noexcept;

    ? Returns: less<T*>()(a.get(), nullptr). 

    template<class T>
bool operator<(nullptr_t, const shared_ptr<T>& a) noexcept;
template<class T>
bool operator>(const shared_ptr<T>& a, nullptr_t) noexcept;

    ? Returns: less<T*>()(nullptr, a.get()). 

    template<class T>
bool operator<=(const shared_ptr<T>& a, nullptr_t) noexcept;
template<class T>
bool operator>=(nullptr_t, const shared_ptr<T>& a) noexcept;

    ? Returns: !(nullptr < a). 

    template<class T>
bool operator<=(nullptr_t, const shared_ptr<T>& a) noexcept;
template<class T>
bool operator>=(const shared_ptr<T>& a, nullptr_t) noexcept;

    ? Returns: !(a < nullptr).

1408. [FCD] Allow recycling of pointers after undeclare_no_pointers

Section: 20.6.4 [util.dynamic.safety] Status: Voting Submitter: BSI Opened: 2010-08-25 Last modified: 2011-03-24

View all other issues in [util.dynamic.safety].

View all issues with Voting status.

Discussion:

Addresses GB-103

The precondition to calling declare_no_pointers is that no bytes in the range "have been previously registered" with this call. As written, this precondition includes bytes in ranges, even after they have been explicitly unregistered with a later call to undeclare_no_pointers.

Proposed resolution:

Update 20.6.4 [util.dynamic.safety] p.9: 

void declare_no_pointers(char *p, size_t n);

9 Requires: No bytes in the specified range have been previously registeredare currently registered with declare_no_pointers(). If the specified range is in an allocated object, then it must be entirely within a single allocated object. The object must be live until the corresponding undeclare_no_pointers() call. [..]

1413. [FCD] Specify whether high_resolution_clock is a distinct type or a typedef

Section: 20.11.7.3 [time.clock.hires] Status: Tentatively NAD Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-03-24

View all issues with Tentatively NAD status.

Discussion:

Addresses US-112

What it means for high_resolution_clock to be a synonym is undefined. If it may or may not be a typedef, then certain classes of programs become unportable.

[ Resolution proposed in ballot comment ]

Require that it be a distinct class type.

[ 2010 Batavia ]

This is not a defect. Threre are a number of places in the standard where we allow implentations to choose their preferred technique, the most obvious example being the iterator/const_iterator types of set.

Typically, this means it is not portable to declare function overloads that differ only in their use of these types.

Proposed resolution:

1418. [FCD] Effects of resize(size()) on a deque

Section: 23.3.3.3 [deque.capacity] Status: Voting Submitter: BSI Opened: 2010-08-25 Last modified: 2011-03-24

View all other issues in [deque.capacity].

View all issues with Voting status.

Discussion:

Addresses GB-113

There is no mention of what happens if sz==size(). While it obviously does nothing I feel a standard needs to say this explicitely.

[ 2010 Batavia ]

Accepted with a simplified resolution turning one of the < comparisons into <=.

Proposed resolution:

Ammend [deque.capacity]

void resize(size_type sz);

Effects: If sz <= size(), equivalent to erase(begin() + sz, end());. If size() < sz, appends sz - size() default constructedvalue initialized elements to the sequence.

1420. [FCD] Effects of resize(size()) on a list

Section: 23.3.5.3 [list.capacity] Status: Voting Submitter: BSI Opened: 2010-08-25 Last modified: 2011-03-24

View all other issues in [list.capacity].

View all issues with Voting status.

Discussion:

Addresses GB-115

There is no mention of what happens if sz==size(). While it obviously does nothing I feel a standard needs to say this explicitely.

[ Resolution proposed in ballot comment ]

Express the semantics as pseudo-code similarly to the way it is done for the copying overload that follows (in p3). Include an else clause that does nothing and covers the sz==size() case.

[ 2010 Batavia ]

Accepted with a simplified resolution turning one of the < comparisons into <=.

Proposed resolution:

Ammend [list.capacity] p1:

void resize(size_type sz);

Effects: If sz <= size(), equivalent to list<T>::iterator it = begin(); advance(it, sz); erase(it, end());. If size() < sz, appends sz - size() default constructed value initialized elements to the sequence.

1438. [FCD] No definition for base()

Section: 26.5.4.2 [rand.adapt.disc] Status: Voting Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-03-24

View all other issues in [rand.adapt.disc].

View all issues with Voting status.

Discussion:

Addresses US-126

Each adaptor has a member function called base() which has no definition.

[ Resolution proposed by ballot comment: ]

Give it the obvious definition.

[ 2010-11-03 Daniel comments and provides a proposed resolution: ]

The following proposal adds noexcept specifiers to the declarations of the base() functions as replacement for a "Throws: Nothing" element.

[ 2010 Batavia: The working group reviewed this issue, and recommended to add the following to the Proposed Resolution. ]

After further review, the working group concurred with the Proposed Resolution.

[Batavia: waiting for WEB to review wording]

Proposed resolution:

  1. Add the following sentence to the end of 26.5.1.5 [rand.req.adapt]/1:

    A random number engine adaptor (commonly shortened to adaptor) a of type A is a random number engine that takes values produced by some other random number engine, and applies an algorithm to those values in order to deliver a sequence of values with different randomness properties. An engine b of type B adapted in this way is termed a base engine in this context. The expression a.base() shall be valid and shall return a const reference to a's base engine.

  2. Change in [rand.adapt.disc]/3, class template discard_block_engine synopsis, the following declaration: 
    // property functions
const Engine& base() const noexcept;
  3. Add the following new prototype description at the end of sub-clause 26.5.4.2 [rand.adapt.disc]: 
    const Engine& base() const noexcept;

    ? Returns: e.

  4. Change in [rand.adapt.ibits]/4, class template independent_bits_engine synopsis, the following declaration: 
    // property functions
const Engine& base() const noexcept;
  5. Add the following new prototype description at the end of sub-clause 26.5.4.3 [rand.adapt.ibits]: 
    const Engine& base() const noexcept;

    ? Returns: e.

  6. Change in 26.5.4.4 [rand.adapt.shuf]/3, class template shuffle_order_engine synopsis, the following declaration: 
    // property functions
const Engine& base() const noexcept;
  7. Add the following new prototype description at the end of sub-clause 26.5.4.4 [rand.adapt.shuf]: 
    const Engine& base() const noexcept;

    ? Returns: e.

1448. [FCD] Concerns about basic_stringbuf::str(basic_string) postconditions

Section: 27.8.2.3 [stringbuf.members] Status: Immediate Submitter: BSI Opened: 2010-08-25 Last modified: 2011-03-24

View all issues with Immediate status.

Discussion:

Addresses GB-124

N3092 27.8.2.3 [stringbuf.members] contains this text specifying the postconditions of basic_stringbuf::str(basic_string):

Postconditions: If mode & ios_base::out is true, pbase() points to the first underlying character and epptr() >= pbase() + s.size() holds; in addition, if mode & ios_base::in is true, pptr() == pbase() + s.data() holds, otherwise pptr() == pbase() is true. [...]

Firstly, there's a simple mistake: It should be pbase() + s.length(), not pbase() + s.data().

Secondly, it doesn't match existing implementations. As far as I can tell, GCC 4.5 does not test for mode & ios_base::in in the second part of that sentence, but for mode & (ios_base::app | ios_base_ate), and Visual C++ 9 for mode & ios_base::app. Besides, the wording of the C++0x draft doesn't make any sense to me. I suggest changing the second part of the sentence to one of the following:

Replace ios_base::in with (ios_base::ate | ios_base::app), but this would require Visual C++ to change (replacing only with ios_base::ate would require GCC to change, and would make ios_base::app completely useless with stringstreams):

in addition, if mode & (ios_base::ate | ios_base::app) is true, pptr() == pbase() + s.length() holds, otherwise pptr() == pbase() is true.

Leave pptr() unspecified if mode & ios_base::app, but not mode & ios_base::ate (implementations already differ in this case, and it is always possible to use ios_base::ate to get the effect of appending, so it is not necessary to require any implementation to change):

in addition, if mode & ios_base::ate is true, pptr() == pbase() + s.length() holds, if neither mode & ios_base::ate nor mode & ios_base::app is true, pptr() == pbase() holds, otherwise pptr() >= pbase() && pptr() <= pbase() + s.length() (which of the values in this range is unspecified).

Slightly stricter:

in addition, if mode & ios_base::ate is true, pptr() == pbase() + s.length() holds, if neither mode & ios_base::ate nor mode & ios_base::app is true, pptr() == pbase() holds, otherwise pptr() == pbase() || pptr() == pbase() + s.length() (which of these two values is unspecified). A small table might help to better explain the three cases. BTW, at the end of the postconditions is this text: "egptr() == eback() + s.size() hold". Is there a perference for basic_string::length or basic_string::size? It doesn't really matter, but it looks a bit inconsistent.

[2011-03-09: Nicolai Josuttis comments and drafts wording]

First, it seems the current wording is just an editorial mistake. When we added issue 432 to the draft standard (in n1733), the wording in the issue:

If mode & ios_base::out is true, initializes the output sequence such that pbase() points to the first underlying character, epptr() points one past the last underlying character, and if (mode & ios_base::ate) is true, pptr() is set equal to epptr() else pptr() is set equal to pbase().

became:

If mode & ios_base::out is true, initializes the output sequence such that pbase() points to the first underlying character, epptr() points one past the last underlying character, and pptr() is equal to epptr() if mode & ios_base::in is true, otherwise pptr() is equal to pbase().

which beside some changes of the order of words changed 

ios_base::ate

into 

ios_base::in

So, from this point of view, clearly mode & ios_base::ate was meant.

Nevertheless, with this proposed resolution we'd have no wording regarding ios_base::app. Currently the only statements about app in the Standard are just in two tables:

Indeed we seem to have different behavior currently in respect to app: For 

stringstream s2(ios_base::out|ios_base::in|ios_base::app);
s2.str("s2 hello");
s1 << "more";

BTW, for fstreams, both implementations append when app is set: If f2.txt has contents "xy",

fstream f2("f2.txt",ios_base::out|ios_base::in|ios_base::app);
f1 << "more";

appends "more" so that the contents is "xymore".

So IMO app should set the write pointer to the end so that each writing appends.

I don't know whether what the standard says is enough. You can argue the statement in Table 125 clearly states that such a buffer should always append, which of course also applies to str() of stringbuffer.

Nevertheless, it doesn't hurt IMO if we clarify the behavior of str() here in respect to app.

[2011-03-10: P.J.Plauger comments:]

I think we should say nothing special about app at construction time (thus leaving the write pointer at the beginning of the buffer). Leave implementers wiggle room to ensure subsequent append writes as they see fit, but don't change existing rules for initial seek position.

[Madrid meeting: It was observed that a different issue should be opened that clarifies the meaning of app for stringstream]

Proposed resolution:

Change 27.8.2.3 [stringbuf.members] p. 3 as indicated:

void str(const basic_string<charT,traits,Allocator>& s);

2 Effects: Copies the content of s into the basic_stringbuf underlying character sequence and initializes the input and output sequences according to mode.

3 Postconditions: If mode & ios_base::out is true, pbase() points to the first underlying character and epptr() >= pbase() + s.size() holds; in addition, if mode & ios_base::inios_base::ate is true, pptr() == pbase() + s.data()s.size() holds, otherwise pptr() == pbase() is true. If mode & ios_base::in is true, eback() points to the first underlying character, and both gptr() == eback() and egptr() == eback() + s.size() hold.

1450. [FCD] Contradiction in regex_constants

Section: 28.5.2 [re.matchflag] Status: Deferred Submitter: BSI Opened: 2010-08-25 Last modified: 2011-03-24

View all issues with Deferred status.

Discussion:

Addresses GB-127

The Bitmask Type requirements in 17.5.2.1.3 [bitmask.types] p.3 say that all elements on a bitmask type have distinct values, but 28.5.2 [re.matchflag] defines regex_constants::match_default and regex_constants::format_default as elements of the bitmask type regex_constants::match_flag_type, both with value 0. This is a contradiction.

[ Resolution proposed by ballot comment: ]

One of the bitmask elements should be removed from the declaration and should be defined separately, in the same manner as ios_base::adjustfield, ios_base::basefield and ios_base::floatfield are defined by 27.5.3.1.2 [ios::fmtflags] p.2 and Table 120. These are constants of a bitmask type, but are not distinct elements, they have more than one value set in the bitmask. regex_constants::format_default should be specified as a constant with the same value as regex_constants::match_default.

[ 2010-10-31 Daniel comments: ]

Strictly speaking, a bitmask type cannot have any element of value 0 at all, because any such value would contradict the requirement expressed in 17.5.2.1.3 [bitmask.types] p. 3:

for any pair Ci and Cj, Ci & Ci is nonzero

So, actually both regex_constants::match_default and regex_constants::format_default are only constants of the type regex_constants::match_flag_type, and no bitmask elements.

[ 2010-11-03 Daniel comments and provides a proposed resolution: ]

The proposed resolution is written against N3126 and considered as a further improvement of the fixes suggested by n3110.

Proposed resolution:

Add the following sentence to 28.5.2 [re.matchflag] paragraph 1:

1 The type regex_constants::match_flag_type is an implementation-defined bitmask type (17.5.2.1.3). Matching a regular expression against a sequence of characters [first,last) proceeds according to the rules of the grammar specified for the regular expression object, modified according to the effects listed in Table 136 for any bitmask elements set. Type regex_constants::match_flag_type also defines the constants regex_constants::match_default and regex_constants::format_default.

1474. [FCD] weak compare-and-exchange confusion

Section: 29.6.5 [atomics.types.operations.req] Status: Tentatively Voting Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-03-24

View all issues with Tentatively Voting status.

Duplicate of: 1470, 1475, 1476, 1477

Discussion:

Addresses US-175, US-165, CH-23, GB-135

29.6.5 [atomics.types.operations.req] p. 25: The first sentence is grammatically incorrect.

[ 2010-10-28 Daniel adds: ]

Duplicate issue 1475 also has a proposed resolution, but both issues are resolved with below proposed resolution.

[ 2011-02-15 Howard fixes numbering, Hans improves the wording ]

[2011-02-24 Reflector discussion]

Moved to Tentatively Ready after 6 votes.

Proposed resolution:

  1. Change 29.6.5 [atomics.types.operations.req] p. 23 as indicated:

    [ Note: For example, tThe effect of the compare-and-exchange operationsatomic_compare_exchange_strong is 

    if (memcmp(object, expected, sizeof(*object)) == 0)
  memcpy(object, &desired, sizeof(*object));
else
  memcpy(expected, object, sizeof(*object));

    — end note ] [..]

  2. Change 29.6.5 [atomics.types.operations.req] p. 25 as indicated:

    25 Remark: The weak compare-and-exchange operations may fail spuriously, that is, return false while leaving the contents of memory pointed to by expected before the operation is the same that same as that of the object and the same as that of expected after the operationA weak compare-and-exchange operation may fail spuriously. That is, even when the contents of memory referred to by expected and object are equal, it may return false and store back to expected the same memory contents that were originally there.. [ Note: This spurious failure enables implementation of compare-and-exchange on a broader class of machines, e.g., loadlocked store-conditional machines. A consequence of spurious failure is that nearly all uses of weak compare-and-exchange will be in a loop.

    When a compare-and-exchange is in a loop, the weak version will yield better performance on some platforms. When a weak compare-and-exchange would require a loop and a strong one would not, the strong one is preferable. — end note ]

1478. [FCD] Clarify race conditions in atomics initialization

Section: 29.6 [atomics.types.operations] Status: Immediate Submitter: BSI Opened: 2010-08-25 Last modified: 2011-03-24

View all other issues in [atomics.types.operations].

View all issues with Immediate status.

Discussion:

Addresses GB-136

GB requests normative clarification in 29.6 [atomics.types.operations] p.4 that concurrent access constitutes a race, as already done on p.6 and p.7.

[ Resolution proposed in ballot comment: ]

Initialisation of atomics:

We believe the intent is that for any atomics there is a distinguished initialisation write, but that this need not happens-before all the other operations on that atomic - specifically so that the initialisation write might be non-atomic and hence give rise to a data race, and hence undefined behaviour, in examples such as this (from Hans): 

atomic<atomic<int> *> p
f()                      |
{ atomic<int>x;          | W_na x
  p.store(&x,mo_rlx);    | W_rlx p=&x
}                        |

(where na is nonatomic and rlx is relaxed). We suspect also that no other mixed atomic/nonatomic access to the same location is intended to be permitted. Either way, a note would probably help.

[2011-02-26: Hans comments and drafts wording]

I think the important point here is to clarify that races on atomics are possible, and can be introduced as a result of non-atomic initialization operations. There are other parts of this that remain unclear to me, such as whether there are other ways to introduce data races on atomics, or whether the races with initialization also introduce undefined behavior by the 3.8 lifetime rules. But I don't think that it is necessary to resolve those issues before releasing the standard. That's particularly true since we've introduced atomic_init, which allows easier ways to construct initialization races.

[2011-03 Madrid]

Accepted to be applied immediately to the WP

Proposed resolution:

  1. Update 29.6.5 [atomics.types.operations.req] p. 5 as follows:

    constexpr A::A(C desired);

    5 Effects: Initializes the object with the value desired. [ Note: Construction is not atomic. — end note ] Initialization is not an atomic operation (1.10) [intro.multithread]. [Note: It is possible to have an access to an atomic object A race with its construction, for example by communicating the address of the just-constructed object A to another thread via memory_order_relaxed atomic operations on a suitable atomic pointer variable, and then immediately accessing A in the receiving thread. This results in undefined behavior. — end note]

  2. In response to the editor comment to 29.6.5 [atomics.types.operations.req] p. 8: The first Effects element is the correct and intended one:

    void atomic_init(volatile A *object, C desired);
void atomic_init(A *object, C desired);

    8 Effects: Non-atomically initializes *object with value desired. This function shall only be applied to objects that have been default constructed, and then only once. [ Note: these semantics ensure compatibility with C. — end note ] [ Note: Concurrent access from another thread, even via an atomic operation, constitutes a data race. — end note ] [Editor's note: The preceding text is from the WD as amended by N3196. N3193 makes different changes, marked up in the paper as follows:] Effects: Dynamically initializes an atomic variable. Non-atomically That is, non-atomically assigns the value desired to *object. [ Note: this operation may need to initialize locks. — end note ] Concurrent access from another thread, even via an atomic operation, constitutes a data race.

1479. [FCD] Fence functions should be extern "C"

Section: 29.8 [atomics.fences] Status: Tentatively Voting Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-03-24

View other active issues in [atomics.fences].

View all other issues in [atomics.fences].

View all issues with Tentatively Voting status.

Discussion:

Addresses US-179

The fence functions (29.8 [atomics.fences] p.5 + p.6) should be extern "C", for C compatibility.

[2011-02-16 Reflector discussion]

Moved to Tentatively Ready after 6 votes.

Proposed resolution:

  1. Change 29.2 [atomics.syn], header <atomic> synopsis as indicated: 
    namespace std {
  [..]
  // 29.8, fences
  extern "C" void atomic_thread_fence(memory_order);
  extern "C" void atomic_signal_fence(memory_order);  
}

  2. Change 29.8 [atomics.fences], p. 5 and p. 6 as indicated:

    extern "C" void atomic_thread_fence(memory_order);

    5 Effects: depending on the value of order, this operation: [..] 

    extern "C" void atomic_signal_fence(memory_order);

    6 Effects: equivalent to atomic_thread_fence(order), except that synchronizes with relationships are established only between a thread and a signal handler executed in the same thread.

1480. [FCD] Atomic fences don't have synchronizes with relation

Section: 29.8 [atomics.fences] Status: Tentatively Voting Submitter: BSI Opened: 2010-08-25 Last modified: 2011-03-24

View other active issues in [atomics.fences].

View all other issues in [atomics.fences].

View all issues with Tentatively Voting status.

Discussion:

Addresses GB-137

Thread fence not only establish synchronizes with relationships, there are semantics of fences that are expressed not in terms of synchronizes with relationships (for example see 29.3 [atomics.order] p.5). These semantics also need to apply to the use of atomic_signal_fence in a restricted way.

[Batavia: Concurrency group discussed issue, and is OK with the proposed resolution.]

[2011-02-26 Reflector discussion]

Moved to Tentatively Ready after 5 votes.

Proposed resolution:

Change 29.8 [atomics.fences] p. 6 as indicated:

void atomic_signal_fence(memory_order);

6 Effects: equivalent to atomic_thread_fence(order), except that synchronizes with relationshipsthe resulting ordering constraints are established only between a thread and a signal handler executed in the same thread.

1487. [FCD] Clock related operations exception specifications conflict

Section: 30.3.2 [thread.thread.this] Status: Immediate Submitter: Switzerland Opened: 2010-08-25 Last modified: 2011-03-24

View all other issues in [thread.thread.this].

View all issues with Immediate status.

Discussion:

Addresses CH-25

Clock related operations are currently not required not to throw. So "Throws: Nothing." is not always true.

[ Resolution proposed by ballot comment: ]

Either require clock related operations not to throw (in 20.10) or change the Throws clauses in 30.3.2. Also possibly add a note that abs_time in the past or negative rel_time is allowed.

[2011-02-10: Howard Hinnant provides a resolution proposal]

[Previous proposed resolution:]

  1. Change the Operational semantics of C1::now() in 20.11.3 [time.clock.req], Table 59 — Clock requirements as follows:

    Table 59 — Clock requirements
    Expression Return type Operational semantics
    C1::now() C1::time_point Returns a time_point object
    representing the current point in time.
    Shall not throw an exception.

[2011-02-19: Daniel comments and suggests an alternative wording]

Imposing the no-throw requirement on C1::now() of any clock time is an overly radical step: It has the indirect consequences that representation types for C1::rep can never by types with dynamic memory managment, e.g. my big_int, which are currently fully supported by the time utilities. Further-on this strong constraint does not even solve the problem described in the issue, because we are still left with the fact that any of the arithmetic operations of C1::rep, C1::duration, and C1::time_point may throw exceptions.

The alternative proposal uses the following strategy: The general Clock requirements remain untouched, but we require that any functions of the library-provided clocks from sub-clause 20.11.7 [time.clock] and their associated types shall not throw exceptions. Second, we replace existing noexcept specifications of functions from Clause 30 that depend on durations, clocks, or time points by wording that clarifies that these functions can only throw, if the operations of user-provided durations, clocks, or time points used as arguments to these functions throw exceptions.

[2011-03-23 Daniel and Peter check and simplify the proposed resolution resulting in this paper]

There is an inherent problem with std::time_point that it doesn't seem to have an equivalent value for ((time_t)-1) that gets returned by C's time() function to signal a problem, e.g., because the underlying hardware is unavailable. After a lot of thinking and checks we came to the resolution that timepoint::max() should be the value to serve as a value signaling errors in cases where we prefer to stick with no-throw conditions. Of-course, user-provided representation types don't need to follow this approach if they prefer exceptions to signal such failures.

the functions now() and from_time_t() can remain noexcept with the solution to return timepoint::max() in case the current time cannot be determined or (time_t)-1 is passed in, respectively.

Based on the previous proposed solution to LWG 1487 we decided that the new TrivialClock requirements should define that now() mustn't throw and return timepoint::max() to signal a problem. That is in line with the C standard where (time_t)-1 signals a problem. Together with a fix to a - we assumed - buggy specifcation in 20.11.3 p2 which uses "happens-before" relationship with something that isn't any action:

2 In Table 59 C1 and C2 denote clock types. t1 and t2 are values returned by C1::now() where the call returning t1 happens before (1.10) the call returning t2 and both of these calls happen before C1::time_point::max().

[2011-03-23 Review with Concurrency group suggested further simplifications and Howard pointed out, that we do not need time_point::max() as a special value.]

also the second "happens before" will be changed to "occurs before" in the english meaning. this is to allow a steady clock to wrap.

Peter updates issue accordingly to discussion.

[Note to the editor: we recommend removal of the following redundant paragraphs in 30.5.2 [thread.condition.condvarany] p. 18 to p. 21, p. 27, p. 28, p. 30, and p. 31 that are defining details for the wait functions that are given by the Effects element. ]

[Note to the editor: we recommend removal of the following redundant paragraphs in 30.5.1 [thread.condition.condvar]: p24-p26, p33-p34, and p36-p37 that are defining details for the wait_for functions. We believe these paragraphs are redundant with respect to the Effects clauses that define semantics based on wait_until. An example of such a specification is the wait() with a predicate. ]

Proposed resolution:

  1. Change p2 in 20.11.3 [time.clock.req] as follows

    2 In Table 59 C1 and C2 denote clock types. t1 and t2 are values returned by C1::now() where the call returning t1 happens before (1.10) the call returning t2 and both of these calls happen occur before C1::time_point::max(). [ Note: This means C1 didn't wrap around between t1 and t2 — end note ]

  2. Add the following new requirement set at the end of sub-clause 20.11.3 [time.clock.req]: [Comment: This requirement set is intentionally incomplete. The reason for this incompleteness is the based on the fact, that if we would make it right for C++0x, we would end up defining something like a complete ArithmeticLike concept for TC::rep, TC::duration, and TC::time_point. But this looks out-of scope for C++0x to me. The effect is that we essentially do not exactly say, which arithmetic or comparison operations can be used in the time-dependent functions from Clause 30, even though I expect that all declared functions of duration and time_point are well-formed and well-defined. — end comment]

    3 [ Note: the relative difference in durations between those reported by a given clock and the SI definition is a measure of the quality of implementation. — end note ]

    ? A type TC meets the TrivialClock requirements if:

    • TC satisfies the Clock requirements (20.11.3 [time.clock.req]),

    • the types TC::rep, TC::duration, and TC::time_point satisfy the requirements of EqualityComparable ( [equalitycomparable]), LessThanComparable ( [lessthancomparable]), DefaultConstructible ( [defaultconstructible]), CopyConstructible ( [copyconstructible]), CopyAssignable ( [copyassignable]), Destructible ( [destructible]), and of numeric types ([numeric.requirements]) [Note: This means in particular, that operations of these types will not throw exceptions — end note ],

    • lvalues of the types TC::rep, TC::duration, and TC::time_point are swappable (17.6.3.2 [swappable.requirements]),

    • the function TC::now() does not throw exceptions, and

    • the type TC::time_point::clock meets the TrivialClock requirements, recursively.

  3. Modify 20.11.7 [time.clock] p. 1 as follows:

    1 - The types defined in this subclause shall satisfy the TrivialClock requirements (20.11.1).

  4. Modify 20.11.7.1 [time.clock.system] p. 1, class system_clock synopsis, as follows:

    class system_clock {
public:
  typedef see below rep;
  typedef ratio<unspecified , unspecified > period;
  typedef chrono::duration<rep, period> duration;
  typedef chrono::time_point<system_clock> time_point;
  static const bool is_monotonic is_steady = unspecified;
  static time_point now() noexcept;
  // Map to C API
  static time_t to_time_t (const time_point& t) noexcept;
  static time_point from_time_t(time_t t) noexcept;
};

  5. Modify the prototype declarations in 20.11.7.1 [time.clock.system] p. 3 + p. 4 as indicated (This edit also fixes the miss of the static specifier in these prototype declarations):

    static time_t to_time_t(const time_point& t) noexcept;

    static time_point from_time_t(time_t t) noexcept;

  6. Modify 20.11.7.2 [time.clock.steady] p. 1, class steady_clock synopsis, as follows:

    class steady_clock {
public:
  typedef unspecified rep;
  typedef ratio<unspecified , unspecified > period;
  typedef chrono::duration<rep, period> duration;
  typedef chrono::time_point<unspecified, duration> time_point;
  static const bool is_monotonic is_steady = true;

  static time_point now() noexcept;
};

  7. Modify 20.11.7.3 [time.clock.hires] p. 1, class high_resolution_clock synopsis, as follows:

    class high_resolution_clock {
public:
  typedef unspecified rep;
  typedef ratio<unspecified , unspecified > period;
  typedef chrono::duration<rep, period> duration;
  typedef chrono::time_point<unspecified, duration> time_point;
  static const bool is_monotonic is_steady = unspecified;

  static time_point now() noexcept;
};

  8. Add a new paragraph at the end of 30.2.4 [thread.req.timing]:

    6 The resolution of timing provided by an implementation depends on both operating system and hardware. The finest resolution provided by an implementation is called the native resolution.

    ? Implementation-provided clocks that are used for these functions shall meet the TrivialClock requirements (20.11.3 [time.clock.req]).

  9. Edit the synopsis of 30.3.2 [thread.thread.this] before p. 1. Note, this duplicates edits also in D/N3267: 

    template <class Clock, class Duration>
void sleep_until(const chrono::time_point<Clock, Duration>& abs_time) noexcept;
template <class Rep, class Period>
void sleep_for(const chrono::duration<Rep, Period>& rel_time) noexcept;

  10. Modify the prototype specifications in 30.3.2 [thread.thread.this] before p. 4 and p. 6 and re-add a Throws element following the Synchronization elements at p. 5 and p. 7:

    template <class Clock, class Duration>
void sleep_until(const chrono::time_point<Clock, Duration>& abs_time) noexcept;

    4 - [...]

    5 - Synchronization: None.

    ? - Throws: Nothing if Clock satisfies the TrivialClock requirements (20.11.3 [time.clock.req]) and operations of Duration do not throw exceptions. [Note: Instantiations of time point types and clocks supplied by the implementation as specified in 20.11.7 [time.clock] do not throw exceptions. — end note] 

    template <class Rep, class Period>
void sleep_for(const chrono::duration<Rep, Period>& rel_time) noexcept;

    6 [...]

    7 Synchronization: None.

    ? Throws: Nothing if operations of chrono::duration<Rep, Period> do not throw exceptions. [Note: Instantiations of duration types supplied by the implementation as specified in 20.11.7 [time.clock] do not throw exceptions. — end note]

  11. Fix a minor incorrectness in p. 5: Duration types need to compare against duration<>::zero(), not 0:

    3 The expression m.try_lock_for(rel_time) shall be well-formed and have the following semantics:

    [...]

    5 Effects: The function attempts to obtain ownership of the mutex within the relative timeout (30.2.4) specified by rel_time. If the time specified by rel_time is less than or equal to 0rel_time.zero(), the function attempts to obtain ownership without blocking (as if by calling try_lock()). The function shall return within the timeout specified by rel_time only if it has obtained ownership of the mutex object. [ Note: As with try_lock(), there is no guarantee that ownership will be obtained if the lock is available, but implementations are expected to make a strong effort to do so. — end note ]

  12. Modify the class timed_mutex synopsis in 30.4.1.3.1 [thread.timedmutex.class] as indicated: Note, this duplicates edits also in D/N3267: 

    class timed_mutex {
public:
  [...]
  template <class Rep, class Period>
    bool try_lock_for(const chrono::duration<Rep, Period>& rel_time) noexcept;
  template <class Clock, class Duration>
    bool try_lock_until(const chrono::time_point<Clock, Duration>& abs_time) noexcept;
  [...]
};

  13. Modify the class recursive_timed_mutex synopsis in 30.4.1.3.2 [thread.timedmutex.recursive] as indicated: Note, this duplicates edits also in D/N3267: 

    class recursive_timed_mutex {
public:
  [...]
  template <class Rep, class Period>
    bool try_lock_for(const chrono::duration<Rep, Period>& rel_time) noexcept;
  template <class Clock, class Duration>
    bool try_lock_until(const chrono::time_point<Clock, Duration>& abs_time) noexcept;
  [...]
};

  14. Modify the class template unique_lock synopsis in 30.4.2.2 [thread.lock.unique] as indicated. Note, this duplicates edits also in D/N3267: 

    template <class Mutex>
class unique_lock {
public:
  [...]
  template <class Clock, class Duration>
    unique_lock(mutex_type& m, const chrono::time_point<Clock, Duration>& abs_time) noexcept;
  template <class Rep, class Period>
    unique_lock(mutex_type& m, const chrono::duration<Rep, Period>& rel_time) noexcept;
  [...]
};

  15. Modify the constructor prototypes in 30.4.2.2.1 [thread.lock.unique.cons] before p. 14 and p. 17 Note, this duplicates edits also in D/N3267: 

    template <class Clock, class Duration>
  unique_lock(mutex_type& m, const chrono::time_point<Clock, Duration>& abs_time) noexcept;

    template <class Rep, class Period>
  unique_lock(mutex_type& m, const chrono::duration<Rep, Period>& rel_time) noexcept;

1494. [FCD] Term "are serialized" not defined

Section: 30.4.4.2 [thread.once.callonce] Status: Tentatively Voting Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-03-24

View all issues with Tentatively Voting status.

Discussion:

Addresses US-190

The term "are serialized" is never defined (30.4.4.2 [thread.once.callonce] p. 2).

[ Resolution proposed by ballot comment: ]

Remove the sentence with "are serialized" from paragraph 2. Add "Calls to call_once on the same once_flag object shall not introduce data races (17.6.4.8)." to paragraph 3.

[ 2010-11-01 Daniel translates NB comment into wording ]

[ 2011-02-17: Hans proposes an alternative resolution ]

[ 2011-02-25: Hans, Clark, and Lawrence update the suggested wording ]

[2011-02-26 Reflector discussion]

Moved to Tentatively Ready after 5 votes.

Proposed resolution:

Change 30.4.4.2 [thread.once.callonce] p.2+3 as indicated:

template<class Callable, class ...Args>
void call_once(once_flag& flag, Callable&& func, Args&&... args);

[..]

2 Effects: Calls to call_once on the same once_flag object are serialized. If there has been a prior effective call to call_once on the same once_flag object, the call to call_once returns without invoking func. If there has been no prior effective call to call_once on the same once_flag object, INVOKE(decay_copy( std::forward<Callable>(func)), decay_copy(std::forward<Args>(args))...) is executed. The call to call_once is effective if and only if INVOKE(decay_copy( std::forward<Callable>(func)), decay_copy(std::forward<Args>(args))...) returns without throwing an exception. If an exception is thrown it is propagated to the caller. An execution of call_once that does not call its func is a passive execution. An execution of call_once that calls its func is an active execution. An active execution shall call INVOKE(decay_copy(std::forward<Callable>(func)), decay_copy(std::forward<Args>(args))...). If such a call to func throws an exception, the execution is exceptional, otherwise it is returning. An exceptional execution shall propagate the exception to the caller of call_once. Among all executions of call_once for any given once_flag: at most one shall be a returning execution; if there is a returning execution, it shall be the last active execution; and there are passive executions only if there is a returning execution. [Note: Passive executions allow other threads to reliably observe the results produced by the earlier returning execution. — end note]

3 Synchronization: The completion of an effective call to call_once on a once_flag object synchronizes with (1.10 [intro.multithread]) all subsequent calls to call_once on the same once_flag object.For any given once_flag: all active executions occur in a total order; completion of an active execution synchronizes with (1.10 [intro.multithread]) the start of the next one in this total order; and the returning execution synchronizes with the return from all passive executions.

1497. [FCD] lock() postcondition can not be generally achieved

Section: 30.5 [thread.condition] Status: Tentatively Voting Submitter: Switzerland Opened: 2010-08-25 Last modified: 2011-03-24

View all other issues in [thread.condition].

View all issues with Tentatively Voting status.

Discussion:

Addresses CH-30

If lock.lock() throws an exception, the postcondition can not be generally achieved.

[ Resolution proposed by ballot comment: ]

Either state that the postcondition might not be achieved, depending on the error condition, or state that terminate() is called in this case.

[ 2010-08-13 Peter Sommerlad comments and provides wording ]

30.5.1 [thread.condition.condvar], 30.5.2 [thread.condition.condvarany]

p. 13, last bullet, and corresponding paragraphs in all wait functions

Problem:
Condition variable wait might fail, because the lock cannot be acquired when notified. CH-30 says: "If lock.lock() throws an exception, the postcondition can not be generally achieved." CH-30 proposes: "Either state that the postcondition might not be achieved, depending on the error condition, or state that terminate() is called in this case."

The discussion in Rapperswil concluded that calling terminate() might be too drastic in this case and a corresponding exception should be thrown/passed on and one should use a lock type that allows querying its status, which unique_lock allows for std::condition_variable

We also had some additional observations while discussing in Rapperswil:

and add the following proposed solution:

[2011-02-27: Daniel adapts numbering to n3225]

Proposed resolution:

  1. Change 30.5.1 [thread.condition.condvar] as indicated: 
    void wait(unique_lock<mutex>& lock);

    9 Requires: lock.owns_lock() is true and lock.mutex() is locked by the calling thread, and either

    • no other thread is waiting on this condition_variable object or
    • lock.mutex() returns the same value for each of the lock arguments supplied by all concurrently waiting (via wait or timed_wait) threads.
    [..]

    11 Postcondition: lock.owns_lock() is true and lock.mutex() is locked by the calling thread.

    [..] 
    template <class Predicate>
void wait(unique_lock<mutex>& lock, Predicate pred);

    ?? Requires: lock.owns_lock() is true and lock.mutex() is locked by the calling thread, and either

    • no other thread is waiting on this condition_variable object or
    • lock.mutex() returns the same value for each of the lock arguments supplied by all concurrently waiting (via wait or timed_wait) threads.

    14 Effects: 

    while (!pred())
  wait(lock);

    ?? Postcondition: lock.owns_lock() is true and lock.mutex() is locked by the calling thread.

    ?? Throws: std::system_error when an exception is required (30.2.2).

    ?? Error conditions:

    • equivalent error condition from lock.lock() or lock.unlock(). 
    template <class Clock, class Duration>
cv_status wait_until(unique_lock<mutex>& lock,
  const chrono::time_point<Clock, Duration>& abs_time);

    15 Requires: lock.owns_lock() is true and lock.mutex() is locked by the calling thread, and either

    • no other thread is waiting on this condition_variable object or
    • lock.mutex() returns the same value for each of the lock arguments supplied by all concurrently waiting (via wait, wait_for, or wait_until) threads.

    [..]

    17 Postcondition: lock.owns_lock() is true and lock.mutex() is locked by the calling thread.

    [..]

    20 Error conditions:

    • operation_not_permitted — if the thread does not own the lock.
    • equivalent error condition from lock.lock() or lock.unlock(). 
    template <class Rep, class Period>
cv_status wait_for(unique_lock<mutex>& lock,
  const chrono::duration<Rep, Period>& rel_time);

    21 Requires: lock.owns_lock() is true and lock.mutex() is locked by the calling thread, and either

    • no other thread is waiting on this condition_variable object or
    • lock.mutex() returns the same value for each of the lock arguments supplied by all concurrently waiting (via wait, wait_for, or wait_until) threads.

    [..]

    24 Postcondition: lock.owns_lock() is true and lock.mutex() is locked by the calling thread.

    [..]

    26 Error conditions:

    • operation_not_permitted — if the thread does not own the lock.
    • equivalent error condition from lock.lock() or lock.unlock(). 
    template <class Clock, class Duration, class Predicate>
bool wait_until(unique_lock<mutex>& lock,
  const chrono::time_point<Clock, Duration>& abs_time,
    Predicate pred);

    ?? Requires: lock.owns_lock() is true and lock.mutex() is locked by the calling thread, and either

    • no other thread is waiting on this condition_variable object or
    • lock.mutex() returns the same value for each of the lock arguments supplied by all concurrently waiting (via wait or timed_wait) threads.

    27 Effects: 

    while (!pred())
  if (wait_until(lock, abs_time) == cv_status::timeout)
    return pred();
return true;

    28 Returns: pred()

    ?? Postcondition: lock.owns_lock() is true and lock.mutex() is locked by the calling thread.

    29 [ Note: The returned value indicates whether the predicate evaluates to true regardless of whether the timeout was triggered. — end note ]

    ?? Throws: std::system_error when an exception is required (30.2.2).

    ?? Error conditions:

    • equivalent error condition from lock.lock() or lock.unlock(). 
    template <class Rep, class Period, class Predicate>
bool wait_for(unique_lock<mutex>& lock,
  const chrono::duration<Rep, Period>& rel_time,
    Predicate pred);

    30 Requires: lock.owns_lock() is true and lock.mutex() is locked by the calling thread, and either

    • no other thread is waiting on this condition_variable object or
    • lock.mutex() returns the same value for each of the lock arguments supplied by all concurrently waiting (via wait, wait_for, or wait_until) threads.

    [..]

    33 Postcondition: lock.owns_lock() is true and lock.mutex() is locked by the calling thread.

    [..]

    37 Error conditions:

    • operation_not_permitted — if the thread does not own the lock.
    • equivalent error condition from lock.lock() or lock.unlock().
  2. Change 30.5.2 [thread.condition.condvarany] as indicated:

    [..] 

    template <class Lock, class Predicate>
void wait(Lock& lock, Predicate pred);

    [Note: if any of the wait functions exits with an exception it is indeterminate if the Lock is held. One can use a Lock type that allows to query that, such as the unique_lock wrapper. — end note]

    11 Effects: 

    while (!pred())
  wait(lock);

    [..]

    31 Error conditions:

    • operation_not_permitted — if the thread does not own the lock.
    • equivalent error condition from lock.lock() or lock.unlock().

1514. [FCD] packaged_task constructors need review

Section: 30.6.9.1 [futures.task.members] Status: Tentatively Voting Submitter: INCITS Opened: 2010-08-25 Last modified: 2011-03-24

View other active issues in [futures.task.members].

View all other issues in [futures.task.members].

View all issues with Tentatively Voting status.

Discussion:

Addresses US-207

The constructor that takes R(*)(ArgTypes...) is not needed; the constructor that takes a callable type works for this argument type. More generally, the constructors for packaged_task should parallel those for function.

[ US-207 Suggested Resolution: ]

Review the constructors for packaged_task and provide the same ones as function, except where inappropriate.

[ 2010-10-22 Howard provides wording, as requested by the LWG in Rapperswil. ]

[2011-02-10 Reflector discussion]

Moved to Tentatively Ready after 5 votes.

Proposed resolution:

Alter the list of constructors in both 30.6.9 [futures.task] and in 30.6.9.1 [futures.task.members] as indicated: 

template <class F>
explicit packaged_task(F f);
template <class F, class Allocator>
explicit packaged_task(allocator_arg_t, const Allocator& a, F f);
explicit packaged_task(R(*f)(ArgTypes...));
template <class F>
explicit packaged_task(F&& f);
template <class F, class Allocator>
explicit packaged_task(allocator_arg_t, const Allocator& a, F&& f);

1521. Requirements on internal pointer representations in containers

Section: 23.2.1 [container.requirements.general] Status: Deferred Submitter: Mike Spertus Opened: 2010-10-16 Last modified: 2011-03-24

View all other issues in [container.requirements.general].

View all issues with Deferred status.

Discussion:

Addresses US-104, US-141

The standard doesn't say that containers should use abstract pointer types internally. Both Howard and Pablo agree that this is the intent. Further, it is necessary for containers to be stored, for example, in shared memory with an interprocess allocator (the type of scenario that allocators are intended to support).

In spite of the (possible) agreement on intent, it is necessary to make this explicit:

An implementations may like to store the result of dereferencing the pointer (which is a raw reference) as an optimization, but that prevents the data structure from being put in shared memory, etc. In fact, a container could store raw references to the allocator, which would be a little weird but conforming as long as it has one by-value copy. Furthermore, pointers to locales, ctypes, etc. may be there, which also prevents the data structure from being put in shared memory, so we should make explicit that a container does not store raw pointers or references at all.

[ Pre-batavia ]

This issue is being opened as part of the response to NB comments US-104/141. See paper N3171 in the pre-Batavia mailing.

[2011-03-23 Madrid meeting]

Deferred

Proposed resolution:

Add to the end of 23.2.1 [container.requirements.general] p. 8:

[..] In all container types defined in this Clause, the member get_allocator() returns a copy of the allocator used to construct the container or, if that allocator has been replaced, a copy of the most recent replacement. The container may not store internal objects whose types are of the form T * or T & except insofar as they are part of the item type or members.

1524. [FCD] Allocation functions are missing happens-before requirements and guarantees

Section: 18.6.1.4 [new.delete.dataraces] Status: Immediate Submitter: Hans Boehm Opened: 2011-02-26 Last modified: 2011-03-24

View all other issues in [new.delete.dataraces].

View all issues with Immediate status.

Discussion:

Addresses US-34

Technical details:

When the same unit of storage is allocated and deallocated repeatedly, operations on it can't be allowed to race between the allocator and the user program. But I don't see any mention of happens-before in the descriptions of allocation and deallocation functions.

Proposed resolution (not wording yet):

[2011-02-26: Hans comments and drafts wording]

The second requirement already exists, almost verbatim, as 18.6.1.4 [new.delete.dataraces] p. 1. I think this is where the statement belongs. However, this paragraph requires work to correctly address the first part of the issue.

[Adopted at Madrid, 2011-03]

Proposed resolution:

Change 18.6.1.4 [new.delete.dataraces] p. 1 as follows:

1 The library versions of operator new and operator delete, user replacement versions of global operator new and operator delete, and the C standard library functions calloc, malloc, realloc, and free shall not introduce data races (1.10 [intro.multithread]) as a result of concurrent calls from different threads. For purposes of determining the existence of data races, the library versions of operator new, user replacement versions of global operator new, and the C standard library functions calloc and malloc shall behave as though they accessed and modified only the storage referenced by the return value. The library versions of operator delete, user replacement versions of operator delete, and the C standard library function free shall behave as though they accessed and modified only the storage referenced by their first argument. The C standard library realloc function shall behave as though it accessed and modified only the storage referenced by its first argument and by its return value. Calls to these functions that allocate or deallocate a particular unit of storage shall occur in a single total order, and each such deallocation call shall happen before the next allocation (if any) in this order.

1525. [FCD] Effects of resize(size()) on a vector

Section: 23.3.6.3 [vector.capacity] Status: Immediate Submitter: BSI Opened: 2011-03-24 Last modified: 2011-03-25

View other active issues in [vector.capacity].

View all other issues in [vector.capacity].

View all issues with Immediate status.

Discussion:

Addresses GB-117

23.3.6.3 [vector.capacity] p. 9 (Same as for 23.3.3.3 [deque.capacity] p. 1 i.e. deque::resize). There is no mention of what happens if sz==size(). While it obviously does nothing I feel a standard needs to say this explicitely.

Suggested resolution:

Append "If sz == size(), does nothing" to the effects.

[2011-03-24 Daniel comments]

During the edit of this issue some non-conflicting overlap with 2033 became obvious. CopyInsertable should be MoveInsertable and there is missing the DefaultConstructible requirements, but this should be fixed by 2033.

Proposed resolution:

Change 23.3.6.3 [vector.capacity] p. 9 as follows:

void resize(size_type sz);

9 Effects: If sz <= size(), equivalent to erase(begin() + sz, end());. If size() < sz, appends sz - size() value-initialized elements to the sequence.

10 Requires: T shall be CopyInsertable into *this.

1526. [FCD] C++ should not impose thread safety requirements on C99 library implementations

Section: 17.6.5.9 [res.on.data.races] Status: Deferred Submitter: BSI Opened: 2011-03-24 Last modified: 2011-03-24

View all issues with Deferred status.

Discussion:

Addresses GB-111

Section 17.6.5.9 [res.on.data.races], Data Race Avoidance, requires the C++ Standard Library to avoid data races that might otherwise result from two threads making calls to C++ Standard Library functions on distinct objects. The C standard library is part of the C++ Standard Library and some C++ Standary library functions (parts of the Localization library, as well as Numeric Conversions in 21.5), are specified to make use of the C standard library. Therefore, the C++ standard indirectly imposes a requirement on the thread safety of the C standard library. However, since the C standard does not address the concept of thread safety conforming C implementations exist that do no provide such guarantees. This conflict needs to be reconciled.

Suggested resolution by national body comment:

remove the requirement to make use of strtol() and sprintf() since these functions depend on the global C locale and thus cannot be made thread safe.

[2011-03-24 Madrid meeting]

Deferred

Rationale:

No consensus to make a change at this time

Proposed resolution:

2000. Missing definition of packaged_task specialization of uses_allocator

Section: 30.6.9.2 [futures.task.nonmembers] Status: Tentatively Voting Submitter: Howard Hinnant Opened: 2010-08-29 Last modified: 2011-03-24

View all issues with Tentatively Voting status.

Discussion:

[futures.task.nonmembers]/3 says: 

   template <class R, class Alloc>
     struct uses_allocator<packaged_task<R>, Alloc>;

This is a declaration, but should be a definition.

Proposed resolution:

Change [futures.task.nonmembers]/3: 

   template <class R, class Alloc>
     struct uses_allocator<packaged_task<R>, Alloc>;
        : true_type {};

2001. Class template basic_regex uses non existent string_type

Section: 28.8.3 [re.regex.assign] Status: Tentatively Voting Submitter: Volker Lukas Opened: 2010-10-21 Last modified: 2011-03-24

View all issues with Tentatively Voting status.

Discussion:

In working draft N3126, subclause 28.8.3 [re.regex.assign], paragraphs 12, 13 and 19, the name string_type is used. This is presumably a typedef for basic_string<value_type>, where value_type is the character type used by basic_regex. The basic_regex template however defines no such typedef, and neither does the <regex> header or the <initializer_list> header included by <regex>.

[ 2010-11-03 Daniel comments and suggests alternative wording: ]

The proposed resolution needs to use basic_string<charT> instead of basic_string<char>

Previous Proposed Resolution:

Make the following changes to [re.regex.assign]: 

basic_regex& assign(const charT* ptr, flag_type f = regex_constants::ECMAScript);

12 Returns: assign(string_typebasic_string<charT>(ptr), f). 

basic_regex& assign(const charT* ptr, size_t len,
  flag_type f = regex_constants::ECMAScript);

13 Returns: assign(string_typebasic_string<charT>(ptr, len), f). 

[..]

template <class InputIterator> 
  basic_regex& assign(InputIterator first, InputIterator last, 
                          flag_type f = regex_constants::ECMAScript);

18 Requires: The type InputIterator shall satisfy the requirements for an Input Iterator (24.2.3).

19 Returns: assign(string_typebasic_string<charT>(first, last), f).

[ 2010 Batavia ]

Unsure if we should just give basic_regex a string_type typedef. Looking for when string_type was introduced into regex. Howard to draft wording for typedef typename traits::string_type string_type, then move to Review.

[ 2011-02-16: Daniel comments and provides an alternative resolution. ]

I'm strongly in favour with the Batavia idea to provide a separate string_type within basic_regex, but it seems to me that the issue resultion should add one more important typedef, namely that of the traits type! Currently, basic_regex is the only template that does not publish the type of the associated traits type. Instead of opening a new issue, I added this suggestion as part of the proposed wording.

[2011-02-24 Reflector discussion]

Moved to Tentatively Ready after 6 votes.

Proposed resolution:

Change the class template basic_regex synopsis, 28.8 [re.regex] p. 3, as indicated:

namespace std {
  template <class charT,
            class traits = regex_traits<charT> >
  class basic_regex {
  public:
    // types:
    typedef charT value_type;
    typedef traits traits_type;
    typedef typename traits::string_type string_type;
    typedef regex_constants::syntax_option_type flag_type;
    typedef typename traits::locale_type locale_type;

    [..]
  };
}

2003. String exception inconsistency in erase.

Section: 21.4.1 [string.require] Status: Open Submitter: José Daniel García Sánchez Opened: 2010-10-21 Last modified: 2011-03-24

View all other issues in [string.require].

View all issues with Open status.

Discussion:

Clause 21.4.1 [string.require]p3 states:

No erase() or pop_back() member function shall throw any exceptions.

However in 21.4.6.5 [string::erase] p2 the first version of erase has

Throws: out_of_range if pos > size().

[2011-03-24 Madrid meeting]

Beman: Don't want to just change this, can we just say "unless otherwise specified"?

Alisdair: Leave open, but update proposed resolution to say something like "unless otherwise specified".

General agreement that it should be corrected but not a stop-ship.

Action: Update proposed wording for issue 2003 as above, but leave Open.

Proposed resolution:

Update [string.require]p/3:

3 No erase() or pop_back() member function shall throw any exceptions.

2004. duration::operator* has template parameters in funny order

Section: 20.11.5.5 [time.duration.nonmember] Status: Tentatively Voting Submitter: P.J. Plauger Opened: 2010-10-14 Last modified: 2011-03-24

View other active issues in [time.duration.nonmember].

View all other issues in [time.duration.nonmember].

View all issues with Tentatively Voting status.

Discussion:

In [time] and [time.duration.nonmember] we have: 

template <class Rep1, class Period, class Rep2>
    duration<typename common_type<Rep1, Rep2>::type, Period>
        operator*(const Rep1& s, const duration<Rep2, Period>& d);

Everywhere else, we always have <rep, period> in that order for a given type. But here, we have Period and Rep2 in reverse order for <Rep2, Period>. This is probably of little importance, since the template parameters are seldom spelled out for a function like this. But changing it now will eliminate a potential source of future errors and confusion.

Proposed resolution:

Change the signature in [time] and [time.duration.nonmember] to: 

template <class Rep1, class PeriodRep2, class Rep2Period>
    duration<typename common_type<Rep1, Rep2>::type, Period>
        operator*(const Rep1& s, const duration<Rep2, Period>& d);

2005. unordered_map::insert(T&&) protection should apply to map too

Section: 23.4.4.4 [map.modifiers], 23.4.5.3 [multimap.modifiers] Status: Review Submitter: P.J. Plauger Opened: 2010-10-14 Last modified: 2011-03-24

View all issues with Review status.

Discussion:

In [unord.map.modifiers], the signature: 

template <class P>
    pair<iterator, bool> insert(P&& obj);

now has an added Remarks paragraph:

Remarks: This signature shall not participate in overload resolution unless P is implicitly convertible to value_type.

The same is true for unordered_multimap.

But neither map nor multimap have this constraint, even though it is a Good Thing(TM) in those cases as well.

[ The submitter suggests: Add the same Remarks clause to [map.modifiers] and [multimap.modifiers]. ]

[ 2010-10-29 Daniel comments: ]

I believe both paragraphs need more cleanup: First, the current Requires element conflict with the Remark; second, it seems to me that the whole single Requires element is intended to be split into a Requires and an Effects element; third, the reference to tuple is incorrect (noticed by Paolo Carlini); fourth, it refers to some non-existing InputIterator parameter relevant for a completely different overload; sixth, the return type of the overload with hint is wrong. The following proposed resolution tries to solve these issues as well and uses similar wording as for the corresponding unordered containers. Unfortunately it has some redundancy over Table 99, but I did not remove the specification because of the more general template parameter P - the Table 99 requirements apply only for an argument identical to value_type.

Proposed resolution:

  1. Change 23.4.4.4 [map.modifiers] around p. 1 as indicated: 
    template <class P> pair<iterator, bool> insert(P&& x);
template <class P> pair<iterator, bool> insert(const_iterator position, P&& x);

    1 Requires: P shall be convertible to value_type is constructible from std::forward<P>(x)..

    If P is instantiated as a reference type, then the argument x is copied from. Otherwise x is considered to be an rvalue as it is converted to value_type and inserted into the map. Specifically, in such cases CopyConstructible is not required of key_type or mapped_type unless the conversion from P specifically requires it (e.g., if P is a tuple<const key_type, mapped_type>, then key_type must be CopyConstructible). The signature taking InputIterator parameters does not require CopyConstructible of either key_type or mapped_type if the dereferenced InputIterator returns a non-const rvalue pair<key_type,mapped_type>. Otherwise CopyConstructible is required for both key_type and mapped_type.
    ? Effects: Inserts x converted to value_type if and only if there is no element in the container with key equivalent to the key of value_type(x). For the second form, the iterator position is a hint pointing to where the search should start.

    ? Returns: For the first form, the bool component of the returned pair object indicates whether the insertion took place and the iterator component - or for the second form the returned iterator - points to the element with key equivalent to the key of value_type(x).

    ? Complexity: Logarithmic in general, but amortized constant if x is inserted right before position.

    ? Remarks: These signatures shall not participate in overload resolution unless P is implicitly convertible to value_type.

  2. Change 23.4.5.3 [multimap.modifiers] around p. 1 as indicated: 
    template <class P> iterator insert(P&& x);
template <class P> iterator insert(const_iterator position, P&& x);

    1 Requires: P shall be convertible to value_type is constructible from std::forward<P>(x).

    If P is instantiated as a reference type, then the argument x is copied from. Otherwise x is considered to be an rvalue as it is converted to value_type and inserted into the map. Specifically, in such cases CopyConstructible is not required of key_type or mapped_type unless the conversion from P specifically requires it (e.g., if P is a tuple<const key_type, mapped_type>, then key_type must be CopyConstructible). The signature taking InputIterator parameters does not require CopyConstructible of either key_type or mapped_type if the dereferenced InputIterator returns a non-const rvalue pair<key_type, mapped_type>. Otherwise CopyConstructible is required for both key_type and mapped_type.
    ? Effects: Inserts x converted to value_type. For the second form, the iterator position is a hint pointing to where the search should start.

    ? Returns: An iterator that points to the element with key equivalent to the key of value_type(x).

    ? Complexity: Logarithmic in general, but amortized constant if x is inserted right before position.

    ? Remarks: These signatures shall not participate in overload resolution unless P is implicitly convertible to value_type.

[ 2010 Batavia: ]

We need is_convertible, not is_constructible, both in ordered and unordered containers.

Proposed resolution:

  1. Add a new Remarks element after 23.4.4.4 [map.modifiers] p. 1: 
    template <class P> pair<iterator, bool> insert(P&& x);
template <class P> pair<iterator, bool> insert(const_iterator position, P&& x);

    1 Requires: P shall be convertible to value_type.

    If P is instantiated as a reference type, then the argument x is copied from. Otherwise x is considered to be an rvalue as it is converted to value_type and inserted into the map. Specifically, in such cases CopyConstructible is not required of key_type or mapped_type unless the conversion from P specifically requires it (e.g., if P is a tuple<const key_type, mapped_type>, then key_type must be CopyConstructible). The signature taking InputIterator parameters does not require CopyConstructible of either key_type or mapped_type if the dereferenced InputIterator returns a non-const rvalue pair<key_type,mapped_type>. Otherwise CopyConstructible is required for both key_type and mapped_type.

    ? Remarks: These signatures shall not participate in overload resolution unless P is implicitly convertible to value_type.

  2. Change 23.4.5.3 [multimap.modifiers] around p. 1 as indicated: 
    template <class P> iterator insert(P&& x);
template <class P> iterator insert(const_iterator position, P&& x);

    1 Requires: P shall be convertible to value_type.

    If P is instantiated as a reference type, then the argument x is copied from. Otherwise x is considered to be an rvalue as it is converted to value_type and inserted into the map. Specifically, in such cases CopyConstructible is not required of key_type or mapped_type unless the conversion from P specifically requires it (e.g., if P is a tuple<const key_type, mapped_type>, then key_type must be CopyConstructible). The signature taking InputIterator parameters does not require CopyConstructible of either key_type or mapped_type if the dereferenced InputIterator returns a non-const rvalue pair<key_type, mapped_type>. Otherwise CopyConstructible is required for both key_type and mapped_type.

    ? Remarks: These signatures shall not participate in overload resolution unless P is implicitly convertible to value_type.

2006. emplace broken for associative containers

Section: 23.2.5 [unord.req] Status: Tentatively NAD Submitter: Pablo Halpern Opened: 2010-10-18 Last modified: 2011-03-24

View other active issues in [unord.req].

View all other issues in [unord.req].

View all issues with Tentatively NAD status.

Discussion:

The current definition of emplace(args) for associative containers as described in Table 99 is:

Requires: T shall be constructible from args.

Effects: Inserts a T object t constructed with std::forward<Args>(args)... if and only if there is no element in the container with key equivalent to the key of t. The bool component of the returned pair is true if and only if the insertion takes place, and the iterator component of the pair points to the element with key equivalent to the key of t.

There is similar language in Table 100 for unordered associative containers.

The first issue is editorial: T should be value_type throughout both tables.

The major issue is that, if the container is map, multimap, unordered_map, or unordered_multimap, then the only way to construct an object of value_type is to supply exactly two arguments for Key and Value, a pair<Key,Value>, or a piecewise_construct_t followed by two tuples. The original emplace() proposal would have allowed you to specify a Key value followed by any number of constructor arguments for Value. When we removed the variadic constructor to pair, this ability went away. I don't think that was deliberate.

Fixing this is non-trivial, I think. I think that emplace() for map and multimap need several overloads: one for each overloaded constructor in pair<Key,Value>, and one for the emplace(Key, valueargs...) case. And it probably needs some SFINAE meta-programming to ensure that the last case doesn't override any of the other ones. Alternatively, one could say that there are exactly two cases: emplace(args) where pair<Key,Value> is constructible from args, and emplace(args) where Key is constructible form the first arg and Value is constructible from the rest.

Alternatively, the status quo is to use piecewise_construct_t if you want to construct an object.

[ 2010 Batavia: ]

N3178 was looked at in session and moved to NAD.

Proposed resolution:

2007. Incorrect specification of return value for map<>::at()

Section: 23.4.4.3 [map.access] Status: Tentatively Voting Submitter: Matt Austern Opened: 2010-11-01 Last modified: 2011-03-24

View all other issues in [map.access].

View all issues with Tentatively Voting status.

Discussion:

In [map.access]/9, the Returns clause for map<Key, T>::at(x) says that it returns "a reference to the element whose key is equivalent to x." That can't be right. The signature for at() says that its return type is T, but the elements of map<Key, T> have type pair<const K, T>. (I checked [unord.map.elem] and found that its specification of at() is correct. This is a problem for map only.)

Proposed resolution:

Change the wording in [map.access]/9 so it's identical to what we already say for operator[], which is unambiguous and correct.

Returns: A reference to the element whose key is equivalentmapped_type corresponding to x in *this.

2008. Conflicting Error Conditions for packaged_task::operator()

Section: 30.6.9.1 [futures.task.members] Status: Immediate Submitter: Pete Becker Opened: 2010-06-21 Last modified: 2011-03-24

View other active issues in [futures.task.members].

View all other issues in [futures.task.members].

View all issues with Immediate status.

Discussion:

The Throws clause for packaged_task::operator() says that it throws "a future_error exception object if there is no associated asynchronous state or the stored task has already been invoked." However, the Error Conditions clause does not define an error condition when the stored task has already been invoked, only when the associated state is already ready (i.e. the invocation has completed).

[2011-02-17 Anthony provides an alternative resolution]

Previous proposed resolution:

Change the first bullet item in 30.6.9.1 [futures.task.members] /22: 

void operator()(ArgTypes... args);

20 ...

21 ...

22 Error conditions:

[Adopted at Madrid, 2011-03]

Proposed resolution:

  1. Change the first bullet item in 30.6.9.1 [futures.task.members] p. 17: 

    void operator()(ArgTypes... args);

    15 ...

    16 ...

    17 Error conditions:

    • promise_already_satisfied if the associated asynchronous state is already readystored task has already been invoked.
    • no_state if *this has no associated asynchronous state.

  2. Change the first bullet item in 30.6.9.1 [futures.task.members] p. 21: 

    void make_ready_at_thread_exit(ArgTypes... args);

    19 ...

    20 ...

    21 Error conditions:

    • promise_already_satisfied if the associated asynchronous state already has a stored value or exceptionstored task has already been invoked.
    • no_state if *this has no associated asynchronous state.

2009. Reporting out-of-bound values on numeric string conversions

Section: 21.5 [string.conversions] Status: Ready Submitter: Alisdair Meredith Opened: 2010-07-19 Last modified: 2011-03-24

View all other issues in [string.conversions].

View all issues with Ready status.

Discussion:

The functions (w)stoi and (w)stof are specified in terms of calling C library APIs for potentially wider types. The integer and floating-point versions have subtly different behaviour when reading values that are too large to convert. The floating point case will throw out_of_bound if the read value is too large to convert to the wider type used in the implementation, but behaviour is undefined if the converted value cannot narrow to a float. The integer case will throw out_of_bounds if the converted value cannot be represented in the narrower type, but throws invalid_argument, rather than out_of_range, if the conversion to the wider type fails due to overflow.

Suggest that the Throws clause for both specifications should be consistent, supporting the same set of fail-modes with the matching set of exceptions.

Proposed resolution:

21.5p3 [string.conversions] 

int stoi(const string& str, size_t *idx = 0, int base = 10);
long stol(const string& str, size_t *idx = 0, int base = 10);
unsigned long stoul(const string& str, size_t *idx = 0, int base = 10);
long long stoll(const string& str, size_t *idx = 0, int base = 10);
unsigned long long stoull(const string& str, size_t *idx = 0, int base = 10);

...

3 Throws: invalid_argument if strtol, strtoul, strtoll, or strtoull reports that no conversion could be performed. Throws out_of_range if strtol, strtoul, strtoll or strtoull sets errno to ERANGE, or if the converted value is outside the range of representable values for the return type.

21.5p6 [string.conversions] 

float stof(const string& str, size_t *idx = 0);
double stod(const string& str, size_t *idx = 0);
long double stold(const string& str, size_t *idx = 0);

...

6 Throws: invalid_argument if strtod or strtold reports that no conversion could be performed. Throws out_of_range if strtod or strtold sets errno to ERANGE or if the converted value is outside the range of representable values for the return type.

2010. is_* traits for binding operations can't be meaningfully specialized

Section: 20.8.9.1.1 [func.bind.isbind] Status: Open Submitter: Sean Hunt Opened: 2010-07-19 Last modified: 2011-03-24

View all other issues in [func.bind.isbind].

View all issues with Open status.

Discussion:

20.8.9.1.1 [func.bind.isbind] says for is_bind_expression:

Users may specialize this template to indicate that a type should be treated as a subexpression in a bind call.

But it also says:

If T is a type returned from bind, is_bind_expression<T> shall be publicly derived from integral_constant<bool, true>, otherwise from integral_constant<bool, false>.

This means that while the user is free to specialize, any specialization would have to be false to avoid violating the second requirement. A similar problem exists for is_placeholder.

[ 2010 Batavia (post meeting session) ]

Alisdair recognises this is clearly a bug introduced by some wording he wrote, the sole purpose of this metafunction is as a customization point for users to write their own bind-expression types that participate in the standard library bind protocol. The consensus was that this should be fixed in Madrid, moved to Open.

Proposed resolution:

2011. unexpected output required of strings

Section: 21.4.8.9 [string.io] Status: Open Submitter: James Kanze Opened: 2010-07-23 Last modified: 2011-03-24

View all other issues in [string.io].

View all issues with Open status.

Discussion:

What should the following code output? 

#include <string>
#include <iostream>
#include <iomanip>

int 
main() 
{ 
   std::string test("0X1Y2Z"); 
   std::cout.fill('*'); 
   std::cout.setf(std::ios::internal, std::ios::adjustfield); 
   std::cout << std::setw(8) << test << std::endl; 
}

I would expect "**0X1Y2Z", and this is what the compilers I have access to (VC++, g++ and Sun CC) do. But according to the standard, it should be "0X**1Y2Z":

21.4.8.9 [string.io]/5: 

template<class charT, class traits, class Allocator>
  basic_ostream<charT, traits>&
    operator<<(basic_ostream<charT, traits>& os, const basic_string<charT,traits,Allocator>& str);

Effects: Behaves as a formatted output function (27.7.3.6.1 [ostream.formatted.reqmts]). After constructing a sentry object, if this object returns true when converted to a value of type bool, determines padding as described in 22.4.2.2.2 [facet.num.put.virtuals], then inserts the resulting sequence of characters seq as if by calling os.rdbuf()->sputn(seq, n), where n is the larger of os.width() and str.size(); then calls os.width(0).

22.4.2.2.2 [facet.num.put.virtuals]/5:

[...]

Stage 3: A local variable is initialized as 

fmtflags adjustfield= (flags & (ios_base::adjustfield));

The location of any padding is determined according to Table 88.

If str.width() is nonzero and the number of charT's in the sequence after stage 2 is less than str.width(), then enough fill characters are added to the sequence at the position indicated for padding to bring the length of the sequence to str.width(). str.width(0) is called.

Table 88 — Fill padding
State Location
adjustfield == ios_base::left pad after
adjustfield == ios_base::right pad before
adjustfield == internal and a sign occurs in the representation pad after the sign
adjustfield == internal and representation after stage 1 began with 0x or 0X pad after x or X
otherwise pad before

Although it's not 100% clear what "the sequence after stage 2" should mean here, when there is no stage 2, the only reasonable assumption is that it is the contents of the string being output. In the above code, the string being output is "0X1Y2Z", which starts with "0X", so the padding should be inserted "after x or X", and not before the string. I believe that this is a defect in the standard, and not in the three compilers I tried.

[ 2010 Batavia (post meeting session) ]

Consensus that all known implementations are consistent, and disagree with the standard. Preference is to fix the standard before implementations start trying to conform to the current spec, as the current implementations have the preferred form. Howard volunteered to drught for Madrid, move to Open.

[2011-03-24 Madrid meeting]

Daniel Krügler volunteered to provide wording, interacting with Dietmar and Bill.

Proposed resolution:

2012. Associative maps should insert pair, not tuple

Section: 23.4 [associative] Status: Open Submitter: Paolo Carlini Opened: 2010-10-29 Last modified: 2011-03-24

View all other issues in [associative].

View all issues with Open status.

Discussion:

I'm seeing something strange in the paragraphs 23.4.4.4 [map.modifiers] and 23.4.5.3 [multimap.modifiers]: they both talk about tuple<const key_type, mapped_type> but I think they should be talking about pair<const key_type, mapped_type> because, among other reasons, a tuple is not convertible to a pair. If I replace tuple with pair everything makes sense to me.

The proposed resolution is obvious.

[ 2010-11-07 Daniel comments ]

This is by far not the only necessary fix within both sub-clauses. For details see the 2010-10-29 comment in 2005.

[2011-03-24 Madrid meeting]

Paolo: Don't think we can do it now.

Daniel K: Agrees.

Proposed resolution:

Apply the resolution proposed by the 2010-10-29 comment in 2005.

2013. Do library implementers have the freedom to add constexpr?

Section: 17.6.5.6 [constexpr.functions] Status: New Submitter: Matt Austern Opened: 2010-11-12 Last modified: 2011-03-24

View all issues with New status.

Discussion:

Suppose that a particular function is not tagged as constexpr in the standard, but that, in some particular implementation, it is possible to write it within the constexpr constraints. If an implementer tags such a function as constexpr, is that a violation of the standard or is it a conforming extension?

There are two questions to consider. First, is this allowed under the as-if rule? Second, if it does not fall under as-if, is there (and should there be) any special license granted to implementers to do this anyway, sort of the way we allow elision of copy constructors even though it is detectable by users?

I believe that this does not fall under "as-if", so implementers probably don't have that freedom today. I suggest changing the WP to grant it. Even if we decide otherwise, however, I suggest that we make it explicit.

Proposed resolution:

In 17.6.4.6 [constexpr.functions], change paragraph 1 to:

This standard explicitly requires that certain standard library functions are constexpr [dcl.constexpr]. Additionally, an implementation may declare any function to be constexpr if that function's definition satisfies the necessary constraints. Within any header that provides any non-defining declarations of constexpr functions or constructors an implementation shall provide corresponding definitions.

2014. More restrictions on macro names

Section: 17.6.4.3.1 [macro.names] Status: Tentatively Voting Submitter: Alberto Ganesh Barbati Opened: 2010-11-16 Last modified: 2011-03-24

View all other issues in [macro.names].

View all issues with Tentatively Voting status.

Discussion:

A program is currently forbidden to use keywords as macro names. This restriction should be strengthened to include all identifiers that could be used by the library as attribute-tokens (for example noreturn, which is used by header <cstdlib>) and the special identifiers introduced recently for override control (these are not currently used in the library public interface, but could potentially be used by the implementation or in future revisions of the library).

[2011-02-10 Reflector discussion]

Moved to Tentatively Ready after 5 votes.

Proposed resolution:

Modify 17.6.4.3.1 [macro.names] paragraph 2 as follows:

A translation unit shall not #define or #undef names lexically identical to keywords, to the identifiers listed in Table X [Identifiers with special meaning], or to the attribute-tokens described in clause 7.6 [dcl.attr].

2015. Incorrect pre-conditions for some type traits

Section: 20.9.4 [meta.unary] Status: New Submitter: Nikolay Ivchenkov Opened: 2010-11-08 Last modified: 2011-03-24

View all other issues in [meta.unary].

View all issues with New status.

Discussion:

According to N3126 ‑ 3.9/9,

"Scalar types, trivial class types (Clause 9), arrays of such types and cv‑qualified versions of these types (3.9.3) are collectively called trivial types."

Thus, an array (possibly of unknown bound) can be trivial type, non‑trivial type, or an array type whose triviality cannot be determined because its element type is incomplete.

According to N3126 ‑ Table 45, preconditions for std::is_trivial are defined as follows:

"T shall be a complete type, (possibly cv-qualified) void, or an array of unknown bound"

It seems that "an array of unknown bound" should be changed to "an array of unknown bound of a complete element type". Preconditions for some other templates (e.g., std::is_trivially_copyable, std::is_standard_layout, std::is_pod, and std::is_literal_type) should be changed similarly.

On the other hand, some preconditions look too restrictive. For example, std::is_empty and std::is_polymorphic might accept any incomplete non‑class type.

[2011-02-18: Daniel provides wording proposal]

While reviewing the individual preconditions I could find three different groups of either too weakening or too strengthening constraints: 

  1. is_empty/is_polymorphic/is_abstract/has_virtual_destructor:

    These traits can only apply for non‑union class types, otherwise the result must always be false

  2. is_base_of:

    Similar to the previous bullet, but the current wording comes already near to that ideal, it only misses to add the non‑union aspect.

  3. is_trivial/is_trivially_copyable/is_standard_layout/is_pod/is_literal_type:

    These traits always require that std::remove_all_extents<T>::type to be cv void or a complete type.

Proposed resolution:

  1. Modify the pre-conditions of the following type traits in 20.9.4.3 [meta.unary.prop], Table 48 — Type property predicates:

    Table 48 — Type property predicates
    Template Condition Preconditions
    ...
    template <class T>
    struct is_trivial;    		 T is a trivial type (3.9) remove_all_extents<T>::type
    shall be a complete type, or (possibly
    cv-qualified) void, or an array of
    unknown bound    .
    template <class T>
    struct is_trivially_copyable;    		 T is a trivially copyable
    type (3.9)    		 remove_all_extents<T>::type
    shall be a complete type, or (possibly
    cv-qualified) void, or an array of
    unknown bound    .
    template <class T>
    struct is_standard_layout;    		 T is a standard-layout
    type (3.9)    		 remove_all_extents<T>::type
    shall be a complete type, or (possibly
    cv-qualified) void, or an array of
    unknown bound    .
    template <class T>
    struct is_pod;    		 T is a POD type (3.9) remove_all_extents<T>::type
    shall be a complete type, or (possibly
    cv-qualified) void, or an array of
    unknown bound    .
    template <class T>
    struct is_literal_type;    		 T is a literal type (3.9) remove_all_extents<T>::type
    shall be a complete type, or (possibly
    cv-qualified) void, or an array of
    unknown bound    .
    template <class T>
    struct is_empty;    		 T is a class type, but not a
    union type, with no
    non-static data members
    other than bit-fields of
    length 0, no virtual
    member functions, no
    virtual base classes, and
    no base class B for which
    is_empty<B>::value is
    false.    		 T shall be a complete type,
    (possibly cv-qualified) void, or
    an array of unknown bound    If T
    is a non‑union class type, T
    shall be a complete type    .
    template <class T>
    struct is_polymorphic;    		 T is a polymorphic
    class (10.3)    		 T shall be a complete type,
    type, (possibly cv-qualified) void, or
    an array of unknown bound    If T
    is a non‑union class type, T
    shall be a complete type    .
    template <class T>
    struct is_abstract;    		 T is an abstract
    class (10.4)    		 T shall be a complete type,
    type, (possibly cv-qualified) void, or
    an array of unknown bound    If T
    is a non‑union class type, T
    shall be a complete type    .
    ...
    template <class T>
    struct has_virtual_destructor;    		 T has a virtual
    destructor (12.4)    		 T shall be a complete type,
    (possibly cv-qualified) void, or
    an array of unknown bound    If T
    is a non‑union class type, T
    shall be a complete type    .

  2. Modify the pre-conditions of the following type traits in 20.9.6 [meta.rel], Table 50 — Type relationship predicates:

    Table 50 — Type relationship predicates
    Template Condition Comments
    ...
    template <class Base, class
    Derived>
    struct is_base_of;    		 Base is a base class of
    Derived (10) without
    regard to cv-qualifiers
    or Base and Derived
    are not unions and
    name the same class
    type without regard to
    cv-qualifiers    		 If Base and Derived are
    non‑union class types
    and are different types
    (ignoring possible cv-qualifiers)
    then Derived shall be a complete
    type. [ Note: Base classes that
    are private, protected, or
    ambigious are, nonetheless, base
    classes. — end note ]
    ...

2016. Allocators must be no-throw swappable

Section: 17.6.3.5 [allocator.requirements] Status: Open Submitter: Daniel Krügler Opened: 2010-11-17 Last modified: 2011-03-24

View all other issues in [allocator.requirements].

View all issues with Open status.

Discussion:

During the Batavia meeting it turned out that there is a definition hole for types satisfying the Allocators requirements: The problem became obvious when it was discussed whether all swap functions of Containers with internal data handles can be safely tagged with noexcept or not. While it is correct that the implicit swap function of an allocator is required to be a no-throw operation (because move/copy-constructors and assignment operators are required to be no-throw functions), there are no such requirements for specialized swap overloads for a particular allocator.

But this requirement is essential because the Containers are required to support swappable Allocators, when the value allocator_traits<>::propagate_on_container_swap evaluates to true.

[2011-02-10 Alberto, Daniel, and Pablo collaborated on the proposed wording]

The proposed resolution (based on N3225) attempts to solve the following problems:

  1. Table 44 — Allocator requirements, expression rows X::propagate_on_container_copy_assignment, X::propagate_on_container_move_assignment, and X::propagate_on_container_swap only describe operations, but no requirements. In fact, if and only if these compile-time predicates evaluate to true, the additional requirements CopyAssignable, no-throw MoveAssignable, and no-throw lvalue Swappable, respectively, are imposed on the allocator types.
  2. 23.2.1 [container.requirements.general] p. 9 misses to refer to the correct swap conditions: The current wording does not relate to 17.6.3.2 [swappable.requirements] as it should and omits to mention that lvalues shall be swapped. Additional there is one situation described twice in p. 8 and p. 9 (undefined behaviour unless a.get_allocator() == b.get_allocator() or allocator_traits<allocator_type>::propagate_on_container_swap::value == true), which should be cleaned up.

Proposed resolution:

  1. Adapt the following three rows from Table 44 — Allocator requirements:

    Table 44 — Allocator requirements
    Expression Return type Assertion/note
    pre-/post-condition     		Default
    X::propagate_on_container_copy_assignment Identical to or derived from true_type
    or false_type    		 true_type only if an allocator of type X should be copied
    when the client container is copy-assigned. See Note B, below.    		 false_type
    X::propagate_on_container_move_assignment Identical to or derived from true_type
    or false_type    		 true_type only if an allocator of type X should be moved
    when the client container is move-assigned. See Note B, below.    		 false_type
    X::propagate_on_container_swap Identical to or derived from true_type
    or false_type    		 true_type only if an allocator of type X should be swapped
    when the client container is swapped. See Note B, below.    		 false_type

  2. Following 17.6.3.5 [allocator.requirements] p. 3 insert a new normative paragraph:

    Note B: If X::propagate_on_container_copy_assignment::value is true, X shall satisfy the CopyAssignable requirements (Table 39 [copyassignable]). If X::propagate_on_container_move_assignment::value is true, X shall satisfy the MoveAssignable requirements (Table 38 [moveassignable]) and the move operation shall not throw exceptions. If X::propagate_on_container_swap::value is true, lvalues of X shall be swappable (17.6.3.2 [swappable.requirements]) and the swap operation shall not throw exceptions.

  3. Modify 23.2.1 [container.requirements.general] p. 8 and p. 9 as indicated:

    8 - [..] The allocator may be replaced only via assignment or swap(). Allocator replacement is performed by copy assignment, move assignment, or swapping of the allocator only if allocator_traits<allocator_type>::propagate_on_container_copy_assignment::value, allocator_traits<allocator_type>::propagate_on_container_move_assignment::value, or allocator_traits<allocator_type>::propagate_on_container_swap::value is true within the implementation of the corresponding container operation. The behavior of a call to a container's swap function is undefined unless the objects being swapped have allocators that compare equal or allocator_traits<allocator_type>::propagate_on_container_swap::value is true. In all container types defined in this Clause, the member get_allocator() returns a copy of the allocator used to construct the container or, if that allocator has been replaced, a copy of the most recent replacement.

    9 - The expression a.swap(b), for containers a and b of a standard container type other than array, shall exchange the values of a and b without invoking any move, copy, or swap operations on the individual container elements. Lvalues of aAny Compare, Pred, or Hash objects belonging to a and b shall be swappable and shall be exchanged by unqualified calls to non-member calling swap as described in 17.6.3.2 [swappable.requirements]. If allocator_traits<allocator_type>::propagate_on_container_swap::value is true, then lvalues of allocator_type shall be swappable and the allocators of a and b shall also be exchanged using a an unqualified call to non-member swap call as described in 17.6.3.2 [swappable.requirements]. Otherwise, theythe allocators shall not be swapped, and the behavior is undefined unless a.get_allocator() == b.get_allocator(). Every iterator referring to an element in one container before the swap shall refer to the same element in the other container after the swap. It is unspecified whether an iterator with value a.end() before the swap will have value b.end() after the swap.

2017. std::reference_wrapper makes incorrect usage of std::result_of

Section: 20.8.3 [refwrap] Status: Tentatively Voting Submitter: Nikolay Ivchenkov Opened: 2010-11-15 Last modified: 2011-03-24

View other active issues in [refwrap].

View all other issues in [refwrap].

View all issues with Tentatively Voting status.

Discussion:

std::reference_wrapper's function call operator uses wrong type encoding for rvalue-arguments. An rvalue-argument of type T must be encoded as T&&, not as just T. 

#include <functional>
#include <iostream>
#include <string>
#include <type_traits>
#include <utility>

template <class F, class... Types>
     typename std::result_of<F (Types...)>::type
         f1(F f, Types&&... params)
{
     return f(std::forward<Types...>(params...));
}

template <class F, class... Types>
     typename std::result_of<F (Types&&...)>::type
         f2(F f, Types&&... params)
{
     return f(std::forward<Types...>(params...));
}

struct Functor
{
     template <class T>
         T&& operator()(T&& t) const
     {
         return static_cast<T&&>(t);
     }
};

int main()
{
     typedef std::string const Str;
     std::cout << f1(Functor(), Str("1")) << std::endl; // (1)
     std::cout << f2(Functor(), Str("2")) << std::endl; // (2)
}

Lets consider the function template f1 (which is similar to std::reference_wrapper's function call operator). In the invocation (1) F is deduced as 'Functor' and Types is deduced as type sequence which consists of one type 'std::string const'. After the substitution we have the following equivalent: 

template <>
    std::result_of<F (std::string const)>::type
        f1<Functor, std::string const>(Functor f, std::string const && params)
{
    return f(std::forward<const std::string>(params));
}

The top-level cv-qualifier in the parameter type of 'F (std::string const)' is removed, so we have 

template <>
    std::result_of<F (std::string)>::type
        f1<Functor, std::string const>(Functor f, std::string const && params)
{
    return f(std::forward<const std::string>(params));
}

Let r be an rvalue of type 'std::string' and cr be an rvalue of type 'std::string const'. The expression Str("1") is cr. The corresponding return type for the invocation 

Functor().operator()(r)

is 'std::string &&'. The corresponding return type for the invocation 

Functor().operator()(cr)

is 'std::string const &&'.

std::result_of<Functor (std::string)>::type is the same type as the corresponding return type for the invocation Functor().operator()(r), i.e. it is 'std::string &&'. As a consequence, we have wrong reference binding in the return statement in f1.

Now lets consider the invocation (2) of the function template f2. When the template arguments are substituted we have the following equivalent: 

template <>
    std::result_of<F (std::string const &&)>::type
        f2<Functor, std::string const>(Functor f, std::string const && params)
{
    return f(std::forward<const std::string>(params));
}

std::result_of<F (std::string const &&)>::type is the same type as 'std::string const &&'. This is correct result.

[ 2010-12-07 Jonathan Wakely comments and suggests a proposed resolution ]

I agree with the analysis and I think this is a defect in the standard, it would be a shame if it can't be fixed.

In the following example one would expect f(Str("1")) and std::ref(f)(Str("2")) to be equivalent but the current wording makes the invocation through reference_wrapper ill-formed: 

#include <functional>
#include <string>

struct Functor
{
   template <class T>
       T&& operator()(T&& t) const
       {
           return static_cast<T&&>(t);
       }
};

int main()
{
   typedef std::string const Str;
   Functor f;
   f( Str("1") );
   std::ref(f)( Str("2") );  // error
}

[ 2010-12-07 Daniel comments and refines the proposed resolution ]

There is one further defect in the usage of result_of within reference_wrapper's function call operator: According to 20.8.3.4 [refwrap.invoke] p. 1 the invokable entity of type T is provided as lvalue, but result_of is fed as if it were an rvalue. This does not only lead to potentially incorrect result types, but it will also have the effect that we could never use the function call operator with a function type, because the type encoding used in result_of would form an invalid function type return a function type. The following program demonstrates this problem: 

#include <functional>

void foo(int) {}

int main()
{
   std::ref(foo)(0);  // error
}

The correct solution is to ensure that T becomes T& within result_of, which solves both problems at once.

[2011-02-24 Reflector discussion]

Moved to Tentatively Ready after 5 votes.

Proposed resolution:

  1. Change the synopsis in 20.8.3 [refwrap] paragraph 1: 

    namespace std {
  template <class T> class reference_wrapper
  {
  public :
    [...]
    // invocation
    template <class... ArgTypes>
    typename result_of<T&(ArgTypes&&...)>::type
    operator() (ArgTypes&&...) const;
  };
}

  2. Change the signature in 20.8.3.4 [refwrap.invoke] before paragraph 1 

    template <class... ArgTypes>
typename result_of<T&(ArgTypes&&... )>::type
operator()(ArgTypes&&... args) const;

    1 Returns: INVOKE(get(), std::forward<ArgTypes>(args)...). (20.8.2)

2018. regex_traits::isctype Returns clause is wrong

Section: 28.7 [re.traits] Status: Open Submitter: Jonathan Wakely Opened: 2010-11-16 Last modified: 2011-03-24

View all other issues in [re.traits].

View all issues with Open status.

Discussion:

28.7 [re.traits] p. 12 says:

returns true if f bitwise or'ed with the result of calling lookup_classname with an iterator pair that designates the character sequence "w" is not equal to 0 and c == '_'

If the bitmask value corresponding to "w" has a non-zero value (which it must do) then the bitwise or with any value is also non-zero, and so isctype('_', f) returns true for any f. Obviously this is wrong, since '_' is not in every ctype category.

There's a similar problem with the following phrases discussing the "blank" char class.

Proposed resolution:

Replace the Returns clause with a description in terms of ctype categories, rather than pseudocode in terms of bitwise operations. (full replacement wording to follow)

2019. isblank not supported by std::locale

Section: 22.3.3.1 [classification] Status: Tentatively Voting Submitter: Jonathan Wakely Opened: 2010-11-16 Last modified: 2011-03-24

View all issues with Tentatively Voting status.

Discussion:

C99 added isblank and iswblank to <locale.h> but <locale> does not provide any equivalent.

[2011-02-24 Reflector discussion]

Moved to Tentatively Ready after 6 votes.

Proposed resolution:

Add to 22.3.3.1 [classification] synopsis:

template <class charT> bool isgraph (charT c, const locale& loc);
template <class charT> bool isblank (charT c, const locale& loc);

Add to 22.4.1 [category.ctype] synopsis:

static const mask xdigit = 1 << 8;
static const mask blank = 1 << 9;
static const mask alnum = alpha | digit;
static const mask graph = alnum | punct;

2020. Time utility arithmetic constexpr functions have invalid effects

Section: 20.11.5.5 [time.duration.nonmember] Status: Tentatively Voting Submitter: Daniel Krügler Opened: 2010-12-06 Last modified: 2011-03-24

View other active issues in [time.duration.nonmember].

View all other issues in [time.duration.nonmember].

View all issues with Tentatively Voting status.

Discussion:

As of issue 1171 several time-utility functions have been marked constexpr. Alas this was done without adapting the corresponding return elements, which has the effect that none of current arithmetic functions of class template duration marked as constexpr can ever be constexpr functions (which makes them ill-formed, no diagnostics required as of recent core rules), because they invoke a non-constant expression, e.g. 20.11.5.5 [time.duration.nonmember]/2: 

template <class Rep1, class Period1, class Rep2, class Period2>
constexpr typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>{>}::type
operator+(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs);

2 Returns: CD(lhs) += rhs.

The real problem is, that we cannot defer to as-if rules here: The returns element specifies an indirect calling contract of a potentially user-defined function. This cannot be the += assignment operator of such a user-defined type, but must be the corresponding immutable binary operator+ (unless we require that += shall be an immutable function which does not really makes sense).

[2011-02-17 Reflector discussion]

Moved to Tentatively Ready after 5 votes.

Proposed resolution:

The suggested wording changes are against the working draft N3242. Additional to the normative wording changes some editorial fixes are suggested.

  1. In 20.11.5.5 [time.duration.nonmember], change the following arithmetic function specifications as follows:

    template <class Rep1, class Period1, class Rep2, class Period2>
constexpr typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>{>}::type
operator+(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs);

    2 Returns: CD(lhs) += rhsCD(CD(lhs).count() + CD(rhs).count()). 

    template <class Rep1, class Period1, class Rep2, class Period2>
constexpr typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>{>}::type
operator-(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs);

    3 Returns: CD(lhs) -= rhsCD(CD(lhs).count() - CD(rhs).count()). 

    template <class Rep1, class Period, class Rep2>
constexpr duration<typename common_type<Rep1, Rep2>::type, Period>
operator*(const duration<Rep1, Period>& d, const Rep2& s);

    4 Remarks: This operator shall not participate in overload resolution unless Rep2 is implicitly convertible to CR(Rep1, Rep2).

    5 Returns: duration<CR(Rep1, Rep2), Period>(d) *= sCD(CD(d).count() * s).

    [...] 

    template <class Rep1, class Period, class Rep2>
constexpr duration<typename common_type<Rep1, Rep2>::type, Period>
operator/(const duration<Rep1, Period>& d, const Rep2& s);

    8 Remarks: This operator shall not participate in overload resolution unless Rep2 is implicitly convertible to CR(Rep1, Rep2) and Rep2 is not an instantiation of duration.

    9 Returns: duration<CR(Rep1, Rep2), Period>(d) /= sCD(CD(d).count() / s).

    [...] 

    template <class Rep1, class Period, class Rep2>
constexpr duration<typename common_type<Rep1, Rep2>::type, Period>
operator%(const duration<Rep1, Period>& d, const Rep2& s);

    11 Remarks: This operator shall not participate in overload resolution unless Rep2 is implicitly convertible to CR(Rep1, Rep2) and Rep2 is not an instantiation of duration.

    12 Returns: duration<CR(Rep1, Rep2), Period>(d) %= sCD(CD(d).count() % s) 

    template <class Rep1, class Period1, class Rep2, class Period2>
constexpr typename common_type<duration<Rep1, Period1>, duration<Rep2, Period2>>::type
operator%(const duration<Rep1, Period1>& lhs, const duration<Rep2, Period2>& rhs);

    13 Returns: common_type<duration<Rep1, Period1>, duration<Rep2, Period2> >::type(lhs) %= rhsCD(CD(lhs).count() % CD(rhs).count()).

2021. Further incorrect usages of result_of

Section: 20.8.9.1.2 [func.bind.bind], 30.6.1 [futures.overview], 30.6.8 [futures.async] Status: Review Submitter: Daniel Krügler Opened: 2010-12-07 Last modified: 2011-03-24

View all other issues in [func.bind.bind].

View all issues with Review status.

Discussion:

Issue 2017 points out some incorrect usages of result_of in the declaration of the function call operator overload of reference_wrapper, but there are more such specification defects:

  1. According to 20.8.9.1.2 [func.bind.bind] p. 3:

    [..] The effect of g(u1, u2, ..., uM) shall be INVOKE(fd, v1, v2, ..., vN, result_of<FD cv (V1, V2, ..., VN)>::type) [..]

    but fd is defined as "an lvalue of type FD constructed from std::forward<F>(f)". This means that the above usage must refer to result_of<FD cv & (V1, V2, ..., VN)> instead.

  2. Similar in 20.8.9.1.2 [func.bind.bind] p. 10 bullet 2 we have:

    if the value of is_bind_expression<TiD>::value is true, the argument is tid(std::forward<Uj>(uj)...) and its type Vi is result_of<TiD cv (Uj...)>::type

    Again, tid is defined as "lvalue of type TiD constructed from std::forward<Ti>(ti)". This means that the above usage must refer to result_of<TiD cv & (Uj...)> instead. We also have similar defect as in 2017 in regard to the argument types, this leads us to the further corrected form result_of<TiD cv & (Uj&&...)>. This is not the end: Since the Vi are similar sensitive to the argument problem, the last part must say:

    "[..] its type Vi is result_of<TiD cv & (Uj&&...)>::type &&"

    (The bound arguments Vi can never be void types, therefore we don't need to use the more defensive std::add_rvalue_reference type trait)

  3. The function template async is declared as follows (the other overload has the same problem):

    template <class F, class... Args>
future<typename result_of<F(Args...)>::type>
async(F&& f, Args&&... args);

    This usage has the some same problems as we have found in reference_wrapper (2017) and more: According to the specification in 30.6.8 [futures.async] the effective result type is that of the call of 

    INVOKE(decay_copy(std::forward<F>(f)), decay_copy(std::forward<Args>(args))...)

    First, decay_copy potentially modifies the effective types to decay<F>::type and decay<Args>::type.... Second, the current specification is not really clear, what the value category of callable type or the arguments shall be: According to the second bullet of 30.6.8 [futures.async] p. 3:

    Invocation of the deferred function evaluates INVOKE(g, xyz) where g is the stored value of decay_copy(std::forward<F>(f)) and xyz is the stored copy of decay_copy(std::forward<Args>(args))....

    This seems to imply that lvalues are provided in contrast to the direct call expression of 30.6.8 [futures.async] p. 2 which implies rvalues instead. The specification needs to be clarified.

Proposed resolution:

The suggested wording changes are against the working draft N3242.

  1. Change 20.8.9.1.2 [func.bind.bind] p. 3 as indicated:

    Returns: A forwarding call wrapper g with a weak result type (20.8.2). The effect of g(u1, u2, ..., uM) shall be INVOKE(fd, v1, v2, ..., vN, result_of<FD cv & (V1, V2, ..., VN)>::type), where cv represents the cv-qualifiers of g and the values and types of the bound arguments v1, v2, ..., vN are determined as specified below. [..]

  2. Change 20.8.9.1.2 [func.bind.bind] p. 10 bullet 2 as indicated:

    if the value of is_bind_expression<TiD>::value is true, the argument is tid(std::forward<Uj>(uj)...) and its type Vi is result_of<TiD cv & (Uj&&...)>::type&&;

  3. This resolution assumes that the wording of 30.6.8 [futures.async] is incorrectly implying rvalues as arguments of INVOKE, those should be lvalues instead.

    Change the function signatures in header <future> synopsis 30.6.1 [futures.overview] p. 1 and in 30.6.8 [futures.async] p. 1 as indicated: 

    template <class F, class... Args>
future<typename result_of<typename decay<F>::type&(typename decay<Args>::type&...)>::type>
async(F&& f, Args&&... args);
template <class F, class... Args>
future<typename result_of<typename decay<F>::type&(typename decay<Args>::type&...)>::type>
async(launch policy, F&& f, Args&&... args);

  4. Change 30.6.8 [futures.async] p. 4 as indicated: [Note: There is one tiny editorial correction that completes one :: scope specifier] [Note: This sub-section need more wording: The call expressions used imply a different value category]

    Returns: an object of type future<typename result_of<typename decay<F>::type&(typename decay<Args>::type&...)>::type> that refers to the associated asynchronous state created by this call to async.

2022. reference_wrapper<T>::result_type is underspecified

Section: 20.8.3 [refwrap] Status: Tentatively Voting Submitter: Daniel Krügler Opened: 2010-12-08 Last modified: 2011-03-24

View other active issues in [refwrap].

View all other issues in [refwrap].

View all issues with Tentatively Voting status.

Discussion:

Issue 1295 correctly removed function types and references to function types from the bullet 1 of 20.8.2 [func.require] p. 3 because neither function types nor function references satisfy the requirements for a target object which is defined to be an object of a callable type. This has the effect that the reference in 20.8.3 [refwrap] p. 2

reference_wrapper has a weak result type (20.8.2).

is insufficient as a reference to define the member type result_type when the template argument T is a function type.

There are basically two approaches to solve the problem:

  1. Extend the definition of a weak result type in 20.8.2 [func.require] p. 3 to both function types and references thereof. This extension must be specified independend from the concept of a call wrapper, though.

  2. Add one extra sentence to 20.8.3 [refwrap] p. 2 that simply defines the member type result_type for reference_wrapper<T>, when T is a function type.

I checked the current usages of weak result type to have a base to argue for one or the other approach. It turns out, that there is no further reference to this definition in regard to function types or references thereof. The only other reference can be found in 20.8.9.1.2 [func.bind.bind] p. 3, where g is required to be a class type.

[2011-02-23 Reflector discussion]

Moved to Tentatively Ready after 5 votes.

Proposed resolution:

The suggested wording changes are against the working draft N3242.

  1. Change 20.8.3 [refwrap] p. 2 as indicated:

    2 reference_wrapper<T> has a weak result type (20.8.2). If T is a function type, result_type shall be a synonym for the return type of T.

2026. hash should be std qualified for unordered container

Section: 23.5 [unord] Status: Tentatively NAD Submitter: Pete Becker Opened: 2011-02-07 Last modified: 2011-03-24

View all other issues in [unord].

View all issues with Tentatively NAD status.

Discussion:

Tom Plum pointed out to me that there's an apparent inconsistency in the std:: qualification of template names in the unordered containers: 

 template <class Key,
           class T,
           class Hash = hash<Key>,
           class Pred = std::equal_to<Key>,
           class Alloc = std::allocator<std::pair<const Key, T> > >
   class unordered_map;

Is there a reason that hash is not qualified with std::? TR1 also does not use std:: here.

[ 2011-02-07 Chris Jefferson adds: ]

I assumed (I might be wrong) it is because hash is designed to be a customisation point, like swap.

[ 2011-02-07 Howard Hinnant adds: ]

I think this is incorrect. We mean std::hash, though clients are free to specialize std::hash on user-defined types. With the possible exception of begin/end (which I'm not sure if we've settled that), swap is the only intended customization point (look up a function by ADL) in the std:: lib.

[ 2011-02-24 Chris Jefferson adds: ]

I recommend NAD, due to 17.6.1.1 [contents] p3:

Whenever a name x defined in the standard library is mentioned, the name x is assumed to be fully qualified as ::std::x, unless explicitly described otherwise. For example, if the Effects section for library function F is described as calling library function G, the function ::std::G is meant.

[2011-02-25 Reflector discussion]

Moved to Tentatively NAD after 5 votes.

Proposed resolution:

2027. Initialization of the stored task of a packaged_task

Section: 30.6.9.1 [futures.task.members] Status: Tentatively Voting Submitter: Alberto Ganesh Barbati Opened: 2011-02-09 Last modified: 2011-03-24

View other active issues in [futures.task.members].

View all other issues in [futures.task.members].

View all issues with Tentatively Voting status.

Discussion:

Related with LWG issue 1514.

The move constructor of packaged_task does not specify how the stored task is constructed. The obvious way is to move-construct it using the task stored in the argument. Moreover, the constructor should be provided with a throws clause similar to one used for the other constructors, as the move constructor of the stored task is not required to be nothrow.

As for the other constructors, the terms "stores a copy of f" do not reflect the intent, which is to allow f to be moved when possible.

[2011-02-25: Alberto updates wording]

[2011-02-26 Reflector discussion]

Moved to Tentatively Ready after 5 votes.

Proposed resolution:

(wording written assuming LWG 1514 is also accepted)

  1. Change 30.6.9.1 [futures.task.members] paragraph 3:

    3 Effects: constructs a new packaged_task object with an associated asynchronous state and stores a copy of f as the object's stored taskinitializes the object's stored task with std::forward<F>(f). The constructors that take an Allocator argument use it to allocate memory needed to store the internal data structures.

  2. Change 30.6.9.1 [futures.task.members] paragraph 5:

    5 Effects: constructs a new packaged_task object and transfers ownership of other's associated asynchronous state to *this, leaving other with no associated asynchronous state. Moves the stored task from other to *this.

2028. messages_base::catalog overspecified

Section: 22.4.7.1 [locale.messages] Status: Ready Submitter: Howard Hinnant Opened: 2011-02-14 Last modified: 2011-03-24

View all issues with Ready status.

Discussion:

In 22.4.7.1 [locale.messages], messages_base::catalog is specified to be a typedef to int. This type is subsequently used to open, access and close catalogs.

However, an OS may have catalog/messaging services that are indexed and managed by types other than int. For example POSIX, publishes the following messaging API: 

typedef unspecified nl_catd;

nl_catd catopen(const char* name , int oflag);
char*   catgets(nl_catd catd, int set_id, int msg_id, const char* s);
int     catclose(nl_catd catd);

I.e., the catalog is managed with an unspecified type, not necessarily an int. Mac OS uses a void* for nl_catd (which is conforming to the POSIX standard). The current messages_base spec effectively outlaws using the built-in OS messaging service supplied for this very purpose!

[2011-02-24: Chris Jefferson updates the proposed wording, changing unspecified to unspecified signed integral type]

[2011-03-02: Daniel updates the proposed wording, changing unspecified signed integral type to unspecified signed integer type (We don't want to allow for bool or char)]

[2011-03-24 Madrid meeting]

Consensus that this resolution is the direction we would like to see.

Proposed resolution:

  1. Modify 22.4.7.1 [locale.messages]:

    namespace std {
  class messages_base {
  public:
    typedef intunspecified signed integer type catalog;
  };
  ...
}

2029. Missing 'noexcept' on basic_regex move-assignment operator

Section: 28.8 [re.regex] Status: Tentatively Voting Submitter: Jonathan Wakely Opened: 2011-02-16 Last modified: 2011-03-24

View all other issues in [re.regex].

View all issues with Tentatively Voting status.

Discussion:

N3149 replaced the "Throws: nothing" clause on basic_regex::assign(basic_regex&&) with the noexcept keyword. The effects of the move-assignment operator are defined in terms of the assign() function, so the "Throws: nothing" applied there too, and a noexcept-specification should be added there too.

[2011-02-24 Reflector discussion]

Moved to Tentatively Ready after 7 votes.

Proposed resolution:

  1. Modify the basic_regex synopsis in 28.8 [re.regex] p. 3:

    namespace std {
  template <class charT,
            class traits = regex_traits<charT> >
  class basic_regex {
  public:
    ...
    basic_regex& operator=(const basic_regex&);
    basic_regex& operator=(basic_regex&&) noexcept;
    basic_regex& operator=(const charT* ptr);
    ...
  };
}

  2. Modify 28.8.3 [re.regex.assign] p. 2:

    basic_regex& operator=(basic_regex&& e) noexcept;

    2 Effects: returns assign(std::move(e)).

2030. packaged_task::result_type should be removed

Section: 30.6.9 [futures.task] Status: Tentatively Voting Submitter: Anthony Williams Opened: 2010-11-12 Last modified: 2011-03-24

View all other issues in [futures.task].

View all issues with Tentatively Voting status.

Discussion:

packaged_task::operator() always returns void, regardless of the return type of the wrapped task. However, packaged_task::result_type is a typedef to the return type of the wrapped task. This is inconsistent with other uses of result_type in the standard, where it matches the return type of operator() (e.g. function, owner_less). This is confusing.

It also violates the TR1 result_of protocol, and thus makes packaged_task harder to use with anything that respects that protocol.

Finally, it is of little use anyway.

packaged_task::result_type should therefore be removed.

[2011-02-24 Reflector discussion]

Moved to Tentatively Ready after 5 votes.

Proposed resolution:

Alter the class definition of packaged_task in 30.6.9 [futures.task] p. 2 as follows:

template<class R, class... ArgTypes>
class packaged_task<R(ArgTypes...)> {
public:
  typedef R result_type;
  [...]
};

2031. std::future<>::share() only applies to rvalues

Section: 30.6.6 [futures.unique_future] Status: Tentatively Voting Submitter: Anthony Williams Opened: 2011-02-17 Last modified: 2011-03-24

View all other issues in [futures.unique_future].

View all issues with Tentatively Voting status.

Discussion:

As specified, future<>::share() has the signature 

shared_future<R> share() &&;

This means that it can only be applied to rvalues. One of the key benefits of share() is that it can be used with the new auto facility: 

std::promise<some_long_winded_type_name> some_promise;
auto f = some_promise.get_future(); // std::future
auto sf = std::move(f).share();

share() is sufficiently explicit that the move should not be required. We should be able to write: 

auto sf = f.share();

[2011-02-22 Reflector discussion]

Moved to Tentatively Ready after 5 votes.

Proposed resolution:

Alter the declaration of share() to remove the "&&" rvalue qualifier in 30.6.6 [futures.unique_future] p. 3, and 30.6.6 [futures.unique_future] p. 11:

shared_future<R> share() &&;

2032. Incorrect synchronization clause of async function

Section: 30.6.8 [futures.async] Status: Immediate Submitter: Alberto Ganesh Barbati Opened: 2011-02-17 Last modified: 2011-03-24

View all other issues in [futures.async].

View all issues with Immediate status.

Discussion:

Clause 30.6.8 [futures.async] has undergone significant rewording in Batavia. Due to co-presence of at least three different sources of modification there is a part where changes have overlapped (marked by an Editor's note), which should be reconciled. Moreover, I believe that a few non-overlapping sentences are now incorrect and should be fixed, so the problem cannot be handled editorially. (See c++std-lib-29667.)

[Adopted in Madrid, 2011-03]

Proposed resolution:

  1. Edit 30.6.4 [futures.state], paragraph 3 as follows.

    An asynchronous return object is an object that reads results from an associated asynchronous state. A waiting function of an asynchronous return object is one that potentially blocks to wait for the associated asynchronous state to be made ready. If a waiting function can return before the state is made ready because of a timeout (30.2.5), then it is a timed waiting function, otherwise it is a non-timed waiting function.

  2. Edit within 30.6.8 [futures.async] paragraph 3 bullet 2 as follows.

    Effects: [...]

    • if policy & launch::deferred is non-zero — [...] The associated asynchronous state is not made ready until the function has completed. The first call to a non-timed waiting function (30.6.4 [futures.state]) requiring a non-timed wait on an asynchronous return object referring to the this associated asynchronous state created by this async call to become ready shall invoke the deferred function in the thread that called the waiting function;. once Once evaluation of INVOKE(g, xyz) begins, the function is no longer considered deferred. [...]

  3. Edit 30.6.8 [futures.async] paragraph 5 as follows.

    Synchronization: Regardless of the provided policy argument,

    • the invocation of async synchronizes with (1.10) the invocation of f. [Note: this statement applies even when the corresponding future object is moved to another thread. —end note]; and
    • the completion of the function f is sequenced before (1.10) the associated asynchronous state is made ready. [Note: f might not be called at all, so its completion might never happen. —end note]

    If policy & launch::async is non-zero, If the implementation chooses the launch::async policy,

    • a call to a waiting function on an asynchronous return object that shares the associated asynchronous state created by this async call shall block until the associated thread has completed, as if joined (30.3.1.5);
    • the join() on the created thread object the associated thread completion synchronizes with (1.10) the return from the first function that successfully detects the ready status of the associated asynchronous state or with the return from the last function that releases the associated asynchronous state returns, whichever happens first. [Editor's note: N3196 changes the following sentence as indicated. N3188 removes the sentence. Please pick one.] If the invocation is deferred, the completion of the invocation of the deferred function synchronizes with the successful return from a call to a waiting function on the associated asynchronous state.

2033. Preconditions of reserve, shrink_to_fit, and resize functions

Section: 23.3.6.3 [vector.capacity], 23.3.3.3 [deque.capacity] Status: Open Submitter: Nikolay Ivchenkov Opened: 2011-02-20 Last modified: 2011-03-24

View other active issues in [vector.capacity].

View all other issues in [vector.capacity].

View all issues with Open status.

Discussion:

I have several questions with regard to the working paper N3225 (C++0x working draft):

  1. Where the working draft specifies preconditions for shrink_to_fit member function of std::vector and std::deque?

  2. Where the working draft specifies preconditions for 'void reserve(size_type n)' member function of std::vector?

  3. Does a call to 'void resize(size_type sz)' of std::vector require the element type to be DefaultConstructible? If yes, why such requirement is not listed in the Requires paragraph?

  4. Does a call to 'void resize(size_type sz)' of std::vector require the element type to be MoveAssignable because the call erase(begin() + sz, end()) mentioned in the Effects paragraph would require the element type to be MoveAssignable?

  5. Why CopyInsertable requirement is used for 'void resize(size_type sz)' of std::vector instead of MoveInsertable requirement?

Proposed resolution:

2035. Output iterator requirements are broken

Section: 24.2.4 [output.iterators] Status: Open Submitter: Daniel Krügler Opened: 2011-02-27 Last modified: 2011-03-24

View other active issues in [output.iterators].

View all other issues in [output.iterators].

View all issues with Open status.

Discussion:

During the Pittsburgh meeting the proposal N3066 became accepted because it fixed several severe issues related to the iterator specification. But the current working draft (N3225) does not reflect all these changes. Since I'm unaware whether every correction can be done editorial, this issue is submitted to take care of that. To give one example: All expressions of Table 108 — "Output iterator requirements" have a post-condition that the iterator is incrementable. This is impossible, because it would exclude any finite sequence that is accessed by an output iterator, such as a pointer to a C array. The N3066 wording changes did not have these effects.

[2011-03-01: Daniel comments:]

This issue has some overlap with the issue 2038 and I would prefer if we could solve both at one location. I suggest the following approach:

  1. The terms dereferencable and incrementable could be defined in a more general way not restricted to iterators (similar to the concepts HasDereference and HasPreincrement from working draft N2914). But on the other hand, all current usages of dereferencable and incrementable are involved with types that satisfy iterator requirements. Thus, I believe that it is sufficient for C++0x to add corresponding definitions to 24.2.1 [iterator.requirements.general] and to let all previous usages of these terms refer to this sub-clause. Since the same problem occurs with the past-the-end iterator, this proposal suggest providing similar references to usages that precede its definition as well.

  2. We also need to ensure that all iterator expressions get either an operational semantics in terms of others or we need to add missing pre- and post-conditions. E.g. we have the following ones without semantics: 

    *r++ = o // output iterator
*r--     // bidirectional iterator

    According to the SGI specification these correspond to 

    { *r = o; ++r; }                         // output iterator
{ reference tmp = *r; --r; return tmp; } // bidirectional iterator

    respectively. Please note especially the latter expression for bidirectional iterator. It fixes a problem that we have for forward iterator as well: Both these iterator categories provide stronger guarantees than input iterator, because the result of the dereference operation is reference, and not only convertible to the value type (The exact form from the SGI documentation does not correctly refer to reference).

[2011-03-14: Daniel comments and updates the suggested wording]

In addition to the before mentioned necessary changes there is another one need, which became obvious due to issue 2042: forward_list<>::before_begin() returns an iterator value which is not dereferencable, but obviously the intention is that it should be incrementable. This leads to the conclusion that imposing dereferencable as a requirement for the expressions ++r is wrong: We only need the iterator to be incrementable. A similar conclusion applies to the expression --r of bidirectional iterators.

Proposed resolution:

  1. Add a reference to 24.2.1 [iterator.requirements.general] to the following parts of the library preceding Clause 24 Iterators library: (I stopped from 23.2.5 [unord.req] on, because the remaining references are the concrete containers)

    1. 17.6.3.2 [swappable.requirements] p. 5:

      5 A type X satisfying any of the iterator requirements (24.2) is ValueSwappable if, for any dereferenceable (24.2.1 [iterator.requirements.general]) object x of type X, *x is swappable.

    2. 17.6.3.5 [allocator.requirements], Table 27 &mdash> "Descriptive variable definitions", row with the expression c:

      a dereferenceable (24.2.1 [iterator.requirements.general]) pointer of type C*

    3. 20.6.3.2 [pointer.traits.functions]:

      Returns: The first template function returns a dereferenceable (24.2.1 [iterator.requirements.general]) pointer to r obtained by calling Ptr::pointer_to(r); […]

    4. 21.4.3 [string.iterators] p. 2:

      Returns: An iterator which is the past-the-end value (24.2.1 [iterator.requirements.general]).

    5. 22.4.5.1.2 [locale.time.get.virtuals] p. 11:

      iter_type do_get(iter_type s, iter_type end, ios_base& f,
  ios_base::iostate& err, tm *t, char format, char modifier) const;

      Requires: t shall be dereferenceable (24.2.1 [iterator.requirements.general]).

    6. 23.2.1 [container.requirements.general] p. 6:

      […] end() returns an iterator which is the past-the-end (24.2.1 [iterator.requirements.general]) value for the container. […]

    7. 23.2.3 [sequence.reqmts] p. 3:

      […] q denotes a valid dereferenceable (24.2.1 [iterator.requirements.general]) const iterator to a, […]

    8. 23.2.4 [associative.reqmts] p. 8 (I omit intentionally one further reference in the same sub-clause):

      […] q denotes a valid dereferenceable (24.2.1 [iterator.requirements.general]) const iterator to a, […]

    9. 23.2.5 [unord.req] p. 10 (I omit intentionally one further reference in the same sub-clause):

      […] q and q1 are valid dereferenceable (24.2.1 [iterator.requirements.general]) const iterators to a, […]

  2. Edit 24.2.1 [iterator.requirements.general] p. 5 as indicated (The intent is to properly define incrementable and to ensure some further library guarantee related to past-the-end iterator values):

    5 Just as a regular pointer to an array guarantees that there is a pointer value pointing past the last element of the array, so for any iterator type there is an iterator value that points past the last element of a corresponding sequence. These values are called past-the-end values. Values of an iterator i for which the expression *i is defined are called dereferenceable. Values of an iterator i for which the expression ++i is defined are called incrementable. The library never assumes that past-the-end values are dereferenceable or incrementable. Iterators can also have singular values that are not associated with any sequence. […]

  3. Modify the column contents of Table 106 — "Iterator requirements", 24.2.2 [iterator.iterators], as indicated:

    Table 106 — Iterator requirements
    Expression Return type Operational semantics Assertion⁄note
    pre-⁄post-condition
    *r reference   pre: r is dereferenceable.
    ++r X&   pre: r is incrementable.

  4. Modify the column contents of Table 107 — "Input iterator requirements", 24.2.3 [input.iterators], as indicated:

    Table 107 — Input iterator requirements (in addition to Iterator)
    Expression Return type Operational semantics Assertion⁄note
    pre-⁄post-condition
    a != b contextually
    convertible to bool    		 !(a == b) pre: (a, b) is in the domain
    of ==.
    *a convertible to T   pre: a is dereferenceable.
    The expression
    (void)*a, *a is equivalent
    to *a.
    If a == b and (a,b) is in
    the domain of == then *a is
    equivalent to *b.
    a->m   (*a).m pre: a is dereferenceable.
    ++r X&   pre: r is dereferenceableincrementable.
    post: r is dereferenceable or
    r is past-the-end.
    post: any copies of the
    previous value of r are no
    longer required either to be
    dereferenceable, incrementable,
    or to be in the domain of ==.
    (void)r++   (void)++r equivalent to (void)++r
    *r++ convertible to T { T tmp = *r;
    ++r;
    return tmp; }     		 

  5. Modify the column contents of Table 108 — "Output iterator requirements", 24.2.4 [output.iterators], as indicated:

    Table 108 — Output iterator requirements (in addition to Iterator)
    Expression Return type Operational semantics Assertion⁄note
    pre-⁄post-condition
    *r = o result is not used   pre: r is dereferenceable.
    Remark: After this operation
    r is not required to be
    dereferenceable.
    post: r is incrementable.
    ++r X&   pre: r is incrementable.
    &r == &++r.
    Remark: After this operation
    r is not required to be
    dereferenceable or incrementable.
    post: r is incrementable.
    r++ convertible to const X& { X tmp = r;
    ++r;
    return tmp; }         		Remark: After this operation
    r is not required to be
    dereferenceable or incrementable.
    post: r is incrementable.
    *r++ = o result is not used { *r = o; ++r; } Remark: After this operation
    r is not required to be
    dereferenceable or incrementable.
    post: r is incrementable.

  6. Modify the column contents of Table 109 — "Forward iterator requirements", 24.2.5 [forward.iterators], as indicated [Rationale: Since the return type of the expression *r++ is now guaranteed to be type reference, the implied operational semantics from input iterator based on value copies is wrong — end rationale]

    Table 109 — Forward iterator requirements (in addition to input iterator)
    Expression Return type Operational semantics Assertion⁄note
    pre-⁄post-condition
    r++ convertible to const X& { X tmp = r;
    ++r;
    return tmp; }         		 
    *r++ reference { reference tmp = *r;
    ++r;
    return tmp; }    		  

  7. Modify the column contents of Table 110 — "Bidirectional iterator requirements", 24.2.6 [bidirectional.iterators], as indicated:

    Table 110 — Bidirectional iterator requirements (in addition to forward iterator)
    Expression Return type Operational semantics Assertion⁄note
    pre-⁄post-condition
    --r X&   pre: there exists s such that
    r == ++s.
    post: r is dereferenceableincrementable.
    --(++r) == r.
    --r == --s implies r == s.
    &r == &--r.
    r-- convertible to const X& { X tmp = r;
    --r;
    return tmp; }         		 
    *r-- reference { reference tmp = *r;
    --r;
    return tmp; }    		  

2038. Missing definition for incrementable iterator

Section: 24.2.4 [output.iterators] Status: Open Submitter: Pete Becker Opened: 2011-02-27 Last modified: 2011-03-24

View other active issues in [output.iterators].

View all other issues in [output.iterators].

View all issues with Open status.

Discussion:

In comp.lang.c++, Vicente Botet raises the following questions:

"In "24.2.4 Output iterators" there are 3 uses of incrementable. I've not found the definition. Could some one point me where it is defined?

Something similar occurs with dereferenceable. While the definition is given in "24.2.1 In general" it is used several times before.

Shouldn't these definitions be moved to some previous section?"

He's right: both terms are used without being properly defined.

There is no definition of "incrementable".

While there is a definition of "dereferenceable", it is, in fact, a definition of "dereferenceable iterator". "dereferenceable" is used throughout Clause 23 (Containers) before its definition in Clause 24. In almost all cases it's referring to iterators, but in 17.6.3.2 [swappable.requirements] there is a mention of "dereferenceable object"; in 17.6.3.5 [allocator.requirements] the table of Descriptive variable definitions refers to a "dereferenceable pointer"; 20.6.3.2 [pointer.traits.functions] refers to a "dereferenceable pointer"; in 22.4.5.1.2 [locale.time.get.virtuals]⁄11 (do_get) there is a requirement that a pointer "shall be dereferenceable". In those specific cases it is not defined.

[2011-03-02: Daniel comments:]

I believe that the currently proposed resolution of issue 2035 solves this issue as well.

Proposed resolution:

2039. Issues with std::reverse and std::copy_if

Section: 25.3.1 [alg.copy], 25.3.10 [alg.reverse] Status: Ready Submitter: Nikolay Ivchenkov Opened: 2011-03-02 Last modified: 2011-03-24

View all issues with Ready status.

Discussion:

  1. In the description of std::reverse

    Effects: For each non-negative integer i <= (last - first)/2, applies iter_swap to all pairs of iterators first + i, (last - i) - 1.

    should be changed to

    Effects: For each non-negative integer i < (last - first)/2, applies iter_swap to all pairs of iterators first + i, (last - i) - 1.

    Here i shall be strictly less than (last - first)/2.

  2. In the description of std::copy_if Returns paragraph is missing.

[2011-03-02: Daniel drafts wording]

Proposed resolution:

  1. Modify 25.3.10 [alg.reverse] p. 1 as indicated:

    1 Effects: For each non-negative integer i <= (last - first)/2, applies iter_swap to all pairs of iterators first + i, (last - i) - 1.

  2. Add the following Returns element after 25.3.1 [alg.copy] p. 9:

    template<class InputIterator, class OutputIterator, class Predicate>
OutputIterator copy_if(InputIterator first, InputIterator last,
   OutputIterator result, Predicate pred);

    8 Requires: The ranges [first,last) and [result,result + (last - first)) shall not overlap.

    9 Effects: Copies all of the elements referred to by the iterator i in the range [first,last) for which pred(*i) is true.

    ?? Returns: The end of the resulting range.

    10 Complexity: Exactly last - first applications of the corresponding predicate.

    11 Remarks: Stable.

2040. Missing type traits related to is_convertible

Section: 20.9 [meta] Status: Open Submitter: Daniel Krügler Opened: 2011-03-03 Last modified: 2011-03-24

View all other issues in [meta].

View all issues with Open status.

Discussion:

When n3142 was suggested, it concentrated on constructions, assignments, and destructions, but overlooked to complement the single remaining compiler-support trait

template <class From, class To> struct is_convertible;

with the no-throw and triviality related aspects as it had been done with the other expression-based traits. Specifically, the current specification misses to add the following traits: 

template <class From, class To> struct is_nothrow_convertible;
template <class From, class To> struct is_trivially_convertible;

In particular the lack of is_nothrow_convertible is severly restricting. This was recently recognized when the proposal for decay_copy was prepared by n3255. There does not exist a portable means to define the correct conditional noexcept specification for the decay_copy function template, which is declared as:

template <class T> 
typename decay<T>::type decay_copy(T&& v) noexcept(???);

The semantics of decay_copy bases on an implicit conversion which again influences the overload set of functions that are viable here. In most circumstances this will have the same effect as comparing against the trait std::is_nothrow_move_constructible, but there is no guarantee for that being the right answer. It is possible to construct examples, where this would lead to the false result, e.g.

struct S {
  S(const S&) noexcept(false);
 
  template<class T>
  explicit S(T&&) noexcept(true);
};

std::is_nothrow_move_constructible will properly honor the explicit template constructor because of the direct-initialization context which is part of the std::is_constructible definition and will in this case select it, such that std::is_nothrow_move_constructible<S>::value == true, but if we had the traits is_nothrow_convertible, is_nothrow_convertible<S, S>::value would evaluate to false, because it would use the copy-initialization context that is part of the is_convertible definition, excluding any explicit constructors and giving the opposite result.

The decay_copy example is surely not one of the most convincing examples, but is_nothrow_convertible has several use-cases, and can e.g. be used to express whether calling the following implicit conversion function could throw an exception or not:

template<class T, class U>
T implicit_cast(U&& u) noexcept(is_nothrow_convertible<U, T>::value) 
{
  return std::forward<U>(u);
}

Therefore I suggest to add the missing trait is_nothrow_convertible and for completeness also the missing trait is_trivially_convertible to 20.9 [meta].

[2011-03-24 Madrid meeting]

Daniel K: This is a new feature so out of scope.

Pablo: Any objections to moving 2040 to Open?

No objections.

Proposed resolution:

  1. Ammend the following declarations to the header <type_traits> synopsis in 20.9.2 [meta.type.synop]:

    namespace std {
  …
  // 20.9.6, type relations:
  template <class T, class U> struct is_same;
  template <class Base, class Derived> struct is_base_of;
  template <class From, class To> struct is_convertible;
  template <class From, class To> struct is_trivially_convertible;
  template <class From, class To> struct is_nothrow_convertible;

  …
}

  2. Modify Table 51 — "Type relationship predicates" as indicated. The removal of the remaining traces of the trait is_explicitly_convertible is an editorial step, it was removed by n3047:

    Table 51 — Type relationship predicates
    Template Condition Comments
    …
    template <class From, class To>
    struct is_convertible;    		 see below From and To shall be complete
    types, arrays of unknown bound, or
    (possibly cv-qualified) void
    types.
    template <class From, class To>
    struct is_explicitly_convertible;    		 is_constructible<To, From>::value a synonym for a two-argument
    version of is_constructible.
    An implementation may define it
    as an alias template.
    template <class From, class To>
    struct is_trivially_convertible;    		 is_convertible<From,
    To>::value     is true and the
    conversion, as defined by
    is_convertible, is known
    to call no operation that is
    not trivial ([basic.types], [special]).    		 From and To shall be complete
    types, arrays of unknown bound,
    or (possibly cv-qualified) void
    types.
    template <class From, class To>
    struct is_nothrow_convertible;    		 is_convertible<From,
    To>::value     is true and the
    conversion, as defined by
    is_convertible, is known
    not to throw any
    exceptions ([expr.unary.noexcept]).    		 From and To shall be complete
    types, arrays of unknown bound,
    or (possibly cv-qualified) void
    types.
    …

2041. Stage 2 accumulate incompatibilty

Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: Immediate Submitter: Howard Hinnant Opened: 2011-03-09 Last modified: 2011-03-24

View other active issues in [facet.num.get.virtuals].

View all other issues in [facet.num.get.virtuals].

View all issues with Immediate status.

Discussion:

num_get Stage 2 accumulation changed between C++03 and the current C++0x working draft. The sentences:

If it is not discarded, then a check is made to determine if c is allowed as the next character of an input field of the conversion specifier returned by stage 1. If so it is accumulated.

have been dropped from 22.4.2.1.2 [facet.num.get.virtuals], Stage 2, paragraph 3 that begins:

If discard is true, […]

Consider this code:

#include <sstream>
#include <iostream>

int main(void)
{
   std::istringstream s("8cz");
   long i = 0;
   char c;
   s >> i;
   if (!s.fail())
       std::cout << "i = " << i << '\n';
   else
   {
       std::cout << "s >> i failed\n";
       s.clear();
   }
   s >> c;
   if (!s.fail())
       std::cout << "c = " << c << '\n';
   else
       std::cout << "s >> c failed\n";
}

C++0x currently prints out:

s >> i failed
c = z

However C++03 conforming implementations will output:

i = 8
c = c

I believe we need to restore C++03 compatibility.

Proposed resolution:

Add to 22.4.2.1.2 [facet.num.get.virtuals], Stage 2:

If discard is true, then if '.' has not yet been accumulated, then the position of the character is remembered, but the character is otherwise ignored. Otherwise, if '.' has already been accumulated, the character is discarded and Stage 2 terminates. If it is not discarded, then a check is made to determine if c is allowed as the next character of an input field of the conversion specifier returned by stage 1. If so it is accumulated.

If the character is either discarded or accumulated then in is advanced by ++in and processing returns to the beginning of stage 2.

2042. Comparing forward_list::before_begin() to forward_list::end()

Section: 23.3.4.3 [forwardlist.iter] Status: Immediate Submitter: Joe Gottman Opened: 2011-03-13 Last modified: 2011-03-24

View all issues with Immediate status.

Discussion:

For an object c of type forward_list<X, Alloc>, the iterators c.before_begin() and c.end() are part of the same underlying sequence, so the expression c.before_begin() == c.end() must be well-defined. But the standard says nothing about what the result of this expression should be. The forward iterator requirements says no dereferenceable iterator is equal to a non-dereferenceable iterator and that two dereferenceable iterators are equal if and only if they point to the same element. But since before_begin() and end() are both non-dereferenceable, neither of these rules applies.

Many forward_list methods, such as insert_after(), have a precondition that the iterator passed to them must not be equal to end(). Thus, user code might look like the following: 

void foo(forward_list<int>& c, forward_list<int>::iterator it)
{
  assert(it != c.end());
  c.insert_after(it, 42);
}

Conversely, before_begin() was specifically designed to be used with methods like insert_after(), so if c.before_begin() is passed to this function the assertion must not fail.

[2011-03-14: Daniel comments and updates the suggested wording]

The suggested wording changes are necessary but not sufficient. Since there does not exist an equivalent semantic definition of cbefore_begin() as we have for cbegin(), this still leaves the question open whether the normative remark applies to cbefore_begin() as well. A simple fix is to define the operational semantics of cbefore_begin() in terms of before_begin().

[2011-03-24 Madrid meeting]

General agreement that this is a serious bug.

Pablo: Any objections to moving 2042 to Immediate?

No objections.

Proposed resolution:

Add to the definition of forward_list::before_begin() 23.3.4.3 [forwardlist.iter] the following:

iterator before_begin();
const_iterator before_begin() const;
const_iterator cbefore_begin() const;

-1- Returns: A non-dereferenceable iterator that, when incremented, is equal to the iterator returned by begin().

-?- Effects: cbefore_begin() is equivalent to const_cast<forward_list const&>(*this).before_begin().

-?- Remarks: before_begin() == end() shall equal false.