Revised 2015-05-23 at 15:05:40 UTC

Unresolved Issues


1173. "Equivalence" wishy-washiness

Section: 17 [library] Status: Open Submitter: David Abrahams Opened: 2009-07-14 Last modified: 2015-04-08

View other active issues in [library].

View all other issues in [library].

View all issues with Open status.

Discussion:

Issue: The CopyConstructible requirements are wishy-washy. It requires that the copy is "equivalent" to the original, but "equivalent" is never defined.

I believe this to be an example of a more general lack of rigor around copy and assignment, although I haven't done the research to dig up all the instances.

It's a problem because if you don't know what CopyConstructible means, you also don't know what it means to copy a pair of CopyConstructible types. It doesn't prevent us from writing code, but it is a hole in our ability to understand the meaning of copy.

Furthermore, I'm pretty sure that vector's copy constructor doesn't require the elements to be EqualityComparable, so that table is actually referring to some ill-defined notion of equivalence when it uses ==.

[ 2009 Santa Cruz: ]

Move to "Open". Dave is right that this is a big issue. Paper D2987 ("Defining Move Special Member Functions", Bjarne Stroustrup and Lawrence Crowl) touches on this but does not solve it. This issue is discussed in Elements of Programming.

[ 2010 Rapperswil: ]

This issue is quite vague, so it is difficult to know if and when it has been resolved. John Lakos wrote a paper covering this area a while back, and there is a real interest in providing some sort of clean-up in the future. We need a more clearly draughted issues with an addressable set of concerns, ideally with a paper proposing a resolution, but for a future revision of the standard. Move to Tentatively NAD Future.

[ Moved to NAD Future at 2010-11 Batavia ]

Proposed resolution:


1175. unordered complexity

Section: 23.2.5 [unord.req] Status: Open Submitter: Pablo Halpern Opened: 2009-07-17 Last modified: 2015-04-08

View other active issues in [unord.req].

View all other issues in [unord.req].

View all issues with Open 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

[ 2011 Bloomington ]

The proposed wording looks good. Move to Review.

[2012, Kona]

Fix up some presentation issues with the wording, combining the big-O expressions into single expressions rather than the sum of two separate big-Os.

Strike "constant or linear", prefer "linear in the number of buckets". This allows for number of buckets being larger than requested n as well.

Default n to "unspecified" rather than "implementation-defined". It seems an un-necessary burden asking vendors to document a quantity that is easily determined through the public API of these classes.

Replace distance(f,l) with "number of elements in the range [f,l)"

Retain in Review with the updated wording

[2012, Portland: Move to Open]

The wording still does not call out Pablo's original concern, that the element constructor is called no more than N times, and that the N squared term applies to moves during rehash.

Inconsistent use of O(n)+O(N) vs. O(n+N), with a preference for the former.

AJM to update wording with a reference to "no more than N element constructor calls".

Matt concerned that calling out the O(n) requirements is noise, and dangerous noise in suggesting a precision we do not mean. The cost of constructing a bucket is very different to constructing an element of user-supplied type.

AJM notes that if there are multiple rehashes, the 'n' complexity is probably not linear.

Matt suggests back to Open, Pablo suggests potentially NAD if we keep revisitting without achieving a resolution.

Matt suggests complexity we are concerned with is the number of operations, such as constructing elements, moving nodes, and comparing/hashing keys. We are less concerned with constructing buckets, which are generally noise in this bigger picture.

[2015-01-29 Telecon]

AM: essentially correct, but do we want to complicate the spec?

HH: Pablo has given us permission to NAD it

JM: when I look at the first change in the P/R I find it mildly disturbing that the existing wording says you have a constant time constructor with a single element even if your n is 10^6, so I think adding this change makes people aware there might be a large cost in initializing the hash table, even though it doesn't show up in user-visible constructions.

HH: one way to avoid that problem is make the default ctor noexcept. Then the container isn't allowed to create an arbitrarily large hash table

AM: but this is the constructor where the user provides n

MC: happy with the changes, except I agree with the editorial recommendation to keep the two 𝒪s separate.

JW: yes, the constant 'k' is different in 𝒪(n) and 𝒪(N)

GR: do we want to talk about buckets at all

JM: yes, good to highlight that bucket construction might be a significant cost

HH: suggest we take the suggestion to split 𝒪(n+N) to 𝒪(n)+𝒪(N) and move to Tentatively Ready

GR: 23.2.1p2 says all complexity requirements are stated solely in terms of the number of operations on the contained object, so we shouldn't be stating complexity in terms of the hash table initialization

HH: channeling Pete, there's an implicit "unless otherwise specified" everywhere.

VV: seem to be requesting modifications that render this not Tentatively Ready

GR: I think it can't be T/R

AM: make the editorial recommendation, consider fixing 23.2.1/3 to give us permission to state complexity in terms of bucket initialization

HH: only set it to Review after we get new wording to review

[2015-02 Cologne]

Update wording, revisit later.

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 unspecifiedimpldefdefault number of buckets in unordered_map. max_load_factor() returns 1.0.

    2 Complexity: ConstantLinear in the number of 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 unspecifiedimpldefdefault 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 quadraticLinear in the number of 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 number of elements in the range [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 unspecifiedimpldefdefault number of buckets in unordered_multimap. max_load_factor() returns 1.0.

    2 Complexity: ConstantLinear in the number of 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 unspecifiedimpldefdefault 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 quadraticLinear in the number of 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 number of elements in the range [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 unspecifiedimpldefdefault number of buckets in unordered_set. max_load_factor() returns 1.0.

    2 Complexity: ConstantLinear in the number of 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 unspecifiedimpldefdefault 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 quadraticLinear in the number of 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 number of elements in the range [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 unspecifiedimpldefdefault number of buckets in unordered_multiset. max_load_factor() returns 1.0.

    2 Complexity: ConstantLinear in the number of 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 unspecifiedimpldefdefault 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 quadraticLinear in the number of 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 number of elements in the range [f,l).


1213. Meaning of valid and singular iterator underspecified

Section: 24.2 [iterator.requirements] Status: Open Submitter: Daniel Krügler Opened: 2009-09-19 Last modified: 2015-05-08

View all other issues in [iterator.requirements].

View all issues with Open 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.7.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

[2014-02-20 Re-open Deferred issues as Priority 4]

Consider to await the paper.

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: 2015-04-08

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.

[ 2011 Bloomington ]

Consensus this is the correct direction, but there are (potentially) missing incrementable preconditions on some table rows, and the Remarks on when an output iterator becomes dereferencable are probably better handled outside the table, in a manner similar to the way we word for input iterators.

There was some concern about redundant pre-conditions when the operational semantic is defined in terms of operations that have preconditions, and a similar level of concern over dropping such redundancies vs. applying a consistent level of redundant specification in all the iterator tables. Wording clean-up in either direction would be welcome.

[2011-08-18: Daniel adapts the proposed resolution to honor the Bloomington request]

There is only a small number of further changes suggested to get rid of superfluous requirements and essentially non-normative assertions. Operations should not have extra pre-conditions, if defined by "in-terms-of" semantics, see e.g. a != b or a->m for Table 107. Further, some remarks, that do not impose anything or say nothing new have been removed, because I could not find anything helpful they provide. E.g. consider the remarks for Table 108 for the operations dereference-assignment and preincrement: They don't provide additional information say nothing surprising. With the new pre-conditions and post-conditions it is implied what the remarks intend to say.

[ 2011-11-03: Some observations from Alexander Stepanov via c++std-lib-31405 ]

The following sentence is dropped from the standard section on OutputIterators:

"In particular, the following two conditions should hold: first, any iterator value should be assigned through before it is incremented (this is, for an output iterator i, i++; i++; is not a valid code sequence); second, any value of an output iterator may have at most one active copy at any given time (for example, i = j; *++i = a; *j = b; is not a valid code sequence)."

[ 2011-11-04: Daniel comments and improves the wording ]

In regard to the first part of the comment, the intention of the newly proposed wording was to make clear that for the expression

*r = o

we have the precondition dereferenceable and the post-condition incrementable. And for the expression

++r

we have the precondition incrementable and the post-condition dereferenceable or past-the-end. This should not allow for a sequence like i++; i++; but I agree that it doesn't exactly say that.

In regard to the second point: To make this point clearer, I suggest to add a similar additional wording as we already have for input iterator to the "Assertion/note" column of the expression ++r:

"Post: any copies of the previous value of r are no longer required to be dereferenceable or incrementable."

The proposed has been updated to honor the observations of Alexander Stepanov.

[2015-02 Cologne]

The matter is complicated, Daniel volunteers to write a paper.

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] p5:

      -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 — "Descriptive variable definitions", row with the expression c:

      a dereferenceable (24.2.1 [iterator.requirements.general]) pointer of type C*

    3. 20.7.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 [Rationale: The wording changes attempt to define a minimal "independent" set of operations, namely *a and ++r, and to specify the semantics of the remaining ones. This approach seems to be in agreement with the original SGI specificationend rationale]:

    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 [Rationale: The wording changes attempt to define a minimal "independent" set of operations, namely *r = o and ++r, and to specify the semantics of the remaining ones. This approach seems to be in agreement with the original SGI specificationend rationale]:

    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 and any copies of
    the previous value of r are no
    longer required to be dereferenceable
    or incrementable.

    post: r is incrementable.
    ++r X&   pre: r is incrementable.
    &r == &++r.
    Remark: After this operation
    r is not required to be
    dereferenceable.
    Remark: After this operation
    r is not required to be
    incrementable and any copies of
    the previous value of r are no
    longer required to be dereferenceable
    or incrementable.

    post: r is dereferenceable
    or r is past-the-end
    incrementable.
    r++ convertible to const X& { X tmp = r;
    ++r;
    return tmp; }
    Remark: After this operation
    r is not required to be
    dereferenceable.
    post: r is incrementable.
    *r++ = o result is not used { *r = o; ++r; } Remark: After this operation
    r is not required to be
    dereferenceable.
    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: 2015-04-08

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.7.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.

[ 2011 Bloomington ]

Agree with Daniel, this will be handled by the resolution of 2035.

Proposed resolution:


2051. Explicit tuple constructors for more than one parameter

Section: 20.4.2 [tuple.tuple], 20.4.2.1 [tuple.cnstr] Status: Open Submitter: Ville Voutilainen Opened: 2011-05-01 Last modified: 2015-04-08

View all other issues in [tuple.tuple].

View all issues with Open status.

Discussion:

One of my constituents wrote the following:

-------snip------------

So far the only use I've found for std::tuple is as an ad-hoc type to emulate multiple return values. If the tuple ctor was made non-explicit one could almost think C++ supported multiple return values especially when combined with std::tie().

// assume types line_segment and point
// assume function double distance(point const&, point const&)

std::tuple<point, point>
closest_points(line_segment const& a, line_segment const& b) {
 point ax;
 point bx;
 /* some math */

 return {ax, bx};
}


double
distance(line_segment const& a, line_segment const& b) {
 point ax;
 point bx;
 std::tie(ax, bx) = closest_points(a, b);

 return distance(ax, bx);
}

-------snap----------

See also the messages starting from lib-29330.

Some notes:

  1. pair allows such a return
  2. a lambda with a deduced return type doesn't allow it for any type
  3. decltype refuses {1, 2}

I would recommend making non-unary tuple constructors non-explicit.

[Bloomington, 2011]

Move to NAD Future, this would be an extension to existing functionality.

[Portland, 2012]

Move to Open at the request of the Evolution Working Group.

Proposed resolution:


2062. Effect contradictions w/o no-throw guarantee of std::function swaps

Section: 20.9.12.2 [func.wrap.func], 20.9.12.2.2 [func.wrap.func.mod] Status: Open Submitter: Daniel Krügler Opened: 2011-05-28 Last modified: 2015-04-08

View other active issues in [func.wrap.func].

View all other issues in [func.wrap.func].

View all issues with Open status.

Discussion:

Howard Hinnant observed in reflector message c++std-lib-30841 that 20.9.12.2 [func.wrap.func] makes the member swap noexcept, even though the non-member swap is not noexcept.

The latter was an outcome of the discussions during the Batavia meeting and the Madrid meeting involving LWG 1349, which seems to indicate that the remaining noexcept specifier at the member swap is incorrect and should be removed.

But if we allow for a potentially throwing member swap of std::function, this causes another conflict with the exception specification for the following member function:

template<class F> function& operator=(reference_wrapper<F> f) noexcept;

Effects: function(f).swap(*this);

Note that in this example the sub-expression function(f) does not cause any problems, because of the nothrow-guarantee given in 20.9.12.2.1 [func.wrap.func.con] p. 10. The problem is located in the usage of the swap which could potentially throw given the general latitude.

So, either the Madrid meeting decision need to be revised (and both member and free swap of std::function should be noexcept), or this function needs to be adapted as well, e.g. by taking the exception-specification away or by changing the semantics.

One argument for "swap-may-throw" would be to allow for small-object optimization techniques where the copy of the target may throw. But given the fact that the swap function has been guaranteed to be "Throws: Nothing" from TR1 on, it seems to me that that there would still be opportunities to perform small-object optimizations just restricted to the set of target copies that cannot throw.

In my opinion member swap of std::function has always been intended to be no-throw, because otherwise there would be no good technical reason to specify the effects of several member functions in terms of the "construct-swap" idiom (There are three functions that are defined this way), which provides the strong exception safety in this case. I suggest to enforce that both member swap and non-member swap of std::function are nothrow functions as it had been guaranteed since TR1 on.

[ 2011 Bloomington ]

Dietmar: May not be swappable in the first place.

Alisdair: This is wide contact. Then we should be taking noexcept off instead of putting it on. This is preferred resolution.

Pablo: This is bigger issue. Specification of assignment in terms of swap is suspect to begin with. It is over specification. How this was applied to string is a better example to work from.

Pablo: Two problems: inconsistency that should be fixed (neither should have noexcept), the other issues is that assignment should not be specified in terms of swap. There are cases where assignment should succeed where swap would fail. This is easier with string as it should follow container rules.

Action Item (Alisdair): There are a few more issues found to file.

Dave: This is because of allocators? The allocator makes this not work.

Howard: There is a type erased allocator in shared_ptr. There is a noexcept allocator in shared_ptr.

Pablo: shared_ptr is a different case. There are shared semantics and the allocator does move around. A function does not have shared semantics.

Alisdair: Function objects think they have unique ownership.

Howard: In function we specify semantics with copy construction and swap.

Action Item (Pablo): Write this up better (why assignment should not be defined in terms of swap)

Howard: Not having trouble making function constructor no throw.

Dietmar: Function must allocate memory.

Howard: Does not put stuff that will throw on copy or swap in small object optimization. Put those on heap. Storing allocator, but has to be no throw copy constructable.

Pablo: Are you allowed to or required to swap or move allocators in case or swap or move.

Dave: An allocator that is type erased should be different...

Pablo: it is

Dave: Do you need to know something about allocator types? But only at construction time.

Pablo: You could have allocators that are different types.

Dave: Swap is two ended operation.

Pablo: Opinion is that both have to say propagate on swap for them to swap.

John: It is not arbitrary. If one person says no. No is no.

Howard: Find noexcept swap to be very useful. Would like to move in that direction and bring container design along.

Dave: If you have something were allocator must not propagate you can detect that at construction time.

...

Pablo: Need to leave this open and discuss in smaller group.

Alisdair: Tried to add boost::any as TR2 proposal and ran into this issue. Only the first place where we run into issues with type erased allocators. Suggest we move it to open.

Action Item: Move to open.

Action Item (Pablo works with Howard and Daniel): Address the more fundamental issue (which may be multiple issues) and write up findings.

[ Original resolution: ]

This wording is relative to the FDIS.

  1. Modify the header <functional> synopsis in 20.9 [function.objects] as indicated:

    namespace std {
      […]
    
      template<class R, class... ArgTypes>
      void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&) noexcept;
    
      […]
    }
    
  2. Modify the class template function synopsis in 20.9.12.2 [func.wrap.func] as indicated:

    namespace std {
      […]
    
      // [func.wrap.func.alg], specialized algorithms:
      template<class R, class... ArgTypes>
      void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&) noexcept;
    
      […]
    }
    
  3. Modify 20.9.12.2.7 [func.wrap.func.alg] as indicated:

    template<class R, class... ArgTypes>
    void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>& f2) noexcept;
    

    -1- Effects: f1.swap(f2);

[2014-02-28 (Post Issaquah), Pablo provides more information]

For cross-referencing purposes: The resolution of this issue should be harmonized with any resolution to LWG 2370, which addresses inappropriate noexcepts in some function constructors.

We have the following choices:

  1. swap() does not throw

    Discussion: This definition is desirable, and allows assignment to be implemented with the strong exception guarantee, but it does have consequences: The implementation cannot use the small-object optimization for a function-object F unless F is NothrowMovable (nothrow-swappable is unimportant because F is not swapped with another F). Note that many functors written before C++11 will not have move constructors decorated with noexcept, so this limitation could affect a lot of code.

    It is not clear what other implementation restrictions might be needed. Allocators are required not to throw on move or copy. Is that sufficient?

  2. swap() can throw

    Discussion: This definition gives maximum latitude to implementation to use small-object optimization. However, the strong guarantee on assignment is difficult to achieve. Should we consider giving up on the strong guarantee? How much are we willing to pessimize code for exceptions?

  3. swap() will not throw if both functions have NoThrowMoveable functors

    Discussion: This definition is similar to option 2, but gives slightly stronger guarantees. Here, swap() can throw, but the programmer can theoretically prevent that from happening. This should be straight-forward to implement and gives the implementation a lot of latitude for optimization. However, because this is a dynamic decision, the program is not as easy to reason about. Also, the strong guarantee for assignment is compromized as in option 2.

Proposed resolution:


2070. allocate_shared should use allocator_traits<A>::construct

Section: 20.8.2.2.6 [util.smartptr.shared.create] Status: Open Submitter: Jonathan Wakely Opened: 2011-07-11 Last modified: 2015-04-08

View all issues with Open status.

Discussion:

20.8.2.2.6 [util.smartptr.shared.create] says:

-2- Effects: Allocates memory suitable for an object of type T and constructs an object in that memory via the placement new expression ::new (pv) T(std::forward<Args>(args)...). The template allocate_shared uses a copy of a to allocate memory. If an exception is thrown, the functions have no effect.

This explicitly requires placement new rather than using allocator_traits<A>::construct(a, (T*)pv, std::forward<Args>(args)...) In most cases that would result in the same placement new expression, but would allow more control over how the object is constructed e.g. using scoped_allocator_adaptor to do uses-allocator construction, or using an allocator declared as a friend to construct objects with no public constructors.

[ 2011-08-16 Bloomington: ]

Agreed to fix in principle, but believe that make_shared and allocate_shared have now diverged enough that their descriptions should be separated. Pablo and Stefanus to provide revised wording.

Daniel's (old) proposed resolution:

This wording is relative to the FDIS.

  1. Change the following paragraphs of 20.8.2.2.6 [util.smartptr.shared.create] as indicated (The suggested removal of the last sentence of p1 is not strictly required to resolve this issue, but is still recommended, because it does not say anything new but may give the impression that it says something new):

    template<class T, class... Args> shared_ptr<T> make_shared(Args&&... args);
    template<class T, class A, class... Args>
      shared_ptr<T> allocate_shared(const A& a, Args&&... args);
    

    -1- Requires: For the template make_shared, tThe expression ::new (pv) T(std::forward<Args>(args)...), where pv has type void* and points to storage suitable to hold an object of type T, shall be well formed. For the template allocate_shared, the expression allocator_traits<A>::construct(a, pt, std::forward<Args>(args)...), where pt has type T* and points to storage suitable to hold an object of type T, shall be well formed. A shall be an allocator ([allocator.requirements]). The copy constructor and destructor of A shall not throw exceptions.

    -2- Effects: Allocates memory suitable for an object of type T and constructs an object in that memory. The template make_shared constructs the object via the placement new expression ::new (pv) T(std::forward<Args>(args)...). The template allocate_shared uses a copy of a to allocate memory and constructs the object by calling allocator_traits<A>::construct(a, pt, std::forward<Args>(args)...). If an exception is thrown, the functions have no effect.

    -3- Returns: A shared_ptr instance that stores and owns the address of the newly constructed object of type T.

    -4- Postconditions: get() != 0 && use_count() == 1

    -5- Throws: bad_alloc, or, for the template make_shared, an exception thrown from the constructor of T, or, for the template allocate_shared, an exception thrown from A::allocate or from allocator_traits<A>::constructfrom the constructor of T.

    -6- Remarks: Implementations are encouraged, but not required, to perform no more than one memory allocation. [ Note: This provides efficiency equivalent to an intrusive smart pointer. — end note ]

    -7- [ Note: These functions will typically allocate more memory than sizeof(T) to allow for internal bookkeeping structures such as the reference counts. — end note ]

[2011-12-04: Jonathan and Daniel improve wording]

See also c++std-lib-31796

[2013-10-13, Ville]

This issue is related to 2089.

[2014-02-15 post-Issaquah session : move to Tentatively NAD]

STL: This takes an allocator, but then ignores its construct. That's squirrely.

Alisdair: The convention is when you take an allocator, you use its construct.

STL: 23.2.1 [container.requirements.general]/3, argh! This fills me with despair, but I understand it now.

STL: Ok, this is some cleanup.

STL: You're requiring b to be of type A and not being rebound, is that an overspecification?

Pablo: Good point. Hmm, that's only a requirement on what must be well-formed.

STL: If it's just a well-formed requirement, then why not just use a directly?

Pablo: Yeah, the well-formed requirement is overly complex. It's not a real call, we could just use a directly. It makes it harder to read.

Alisdair: b should be an allocator in the same family as a.

Pablo: This is a well-formed requirement, I wonder if it's the capital A that's the problem here. It doesn't matter here, this is way too much wording.

Alisdair: It's trying to tie the constructor arguments into the allocator requirements.

Pablo: b could be struck, that's a runtime quality. The construct will work with anything that's in the family of A.

Alisdair: The important part is the forward of Args.

Pablo: A must be an allocator, and forward Args must work with that.

Alisdair: First let's nail down A.

Pablo: Then replace b with a, and strike the rest.

STL: You need pt's type, at least.

Pablo: There's nothing to be said about runtime constraints here, this function doesn't even take a pt.

STL: Looking at the Effects, I believe b is similarly messed up, we can use a2 to construct an object.

Alisdair: Or any allocator in the family of a.

STL: We say this stuff for the deallocate too, it should be lifted up.

STL: "owns the address" is weird.

Alisdair: shared_ptr owns pointers, although it does sound funky.

Walter: "to destruct" is ungrammatical.

STL: "When ownership is given up" is not what we usually say.

Alisdair: I think the Returns clause is the right place to say this.

STL: The right place to say this is shared_ptr's dtor, we don't want to use Core's "come from" convention.

Alisdair: I'm on the hook to draft cleaner wording.

Proposed resolution:

This wording is relative to the FDIS.

  1. Change the following paragraphs of 20.8.2.2.6 [util.smartptr.shared.create] as indicated:

    template<class T, class... Args> shared_ptr<T> make_shared(Args&&... args);
    template<class T, class A, class... Args>
      shared_ptr<T> allocate_shared(const A& a, Args&&... args);
    

    -1- Requires: The expression ::new (pv) T(std::forward<Args>(args)...), where pv has type void* and points to storage suitable to hold an object of type T, shall be well formed. A shall be an allocator (17.6.3.5 [allocator.requirements]). The copy constructor and destructor of A shall not throw exceptions.

    -2- Effects: Equivalent to

     
    return allocate_shared<T>(allocator<T>(), std::forward<Args>(args)...);
    

    Allocates memory suitable for an object of type T and constructs an object in that memory via the placement new expression ::new (pv) T(std::forward<Args>(args)...). The template allocate_shared uses a copy of a to allocate memory. If an exception is thrown, the functions have no effect.

    -?- Remarks: An implementation may meet the effects (and the implied guarantees) without creating the allocator object [Note: That is, user-provided specializations of std::allocator may not be instantiated, the expressions ::new (pv) T(std::forward<Args>(args)...) and pv->~T() may be evaluated directly — end note].

    -3- Returns: A shared_ptr instance that stores and owns the address of the newly constructed object of type T.

    -4- Postconditions: get() != 0 && use_count() == 1

    -5- Throws: bad_alloc, or an exception thrown from A::allocate or from the constructor of T.

    -6- Remarks: Implementations are encouraged, but not required, to perform no more than one memory allocation. [Note: This provides efficiency equivalent to an intrusive smart pointer. — end note]

    -7- [Note: These functions will typically allocate more memory than sizeof(T) to allow for internal bookkeeping structures such as the reference counts. — end note]

  2. Add the following set of new paragraphs immediately following the previous paragraph 7 of 20.8.2.2.6 [util.smartptr.shared.create]:

    template<class T, class A, class... Args>
      shared_ptr<T> allocate_shared(const A& a, Args&&... args);
    

    -?- Requires: The expressions allocator_traits<A>::construct(b, pt, std::forward<Args>(args)...) and allocator_traits<A>::destroy(b, pt) shall be well-formed and well-defined, where b has type A and is a copy of a and where pt has type T* and points to storage suitable to hold an object of type T. A shall meet the allocator requirements (17.6.3.5 [allocator.requirements]).

    -?- Effects: Uses an object a2 of type allocator_traits<A>::rebind_alloc<unspecified> that compares equal to a to allocate memory suitable for an object of type T. Uses a copy b of type A from a to construct an object of type T in that memory by calling allocator_traits<A>::construct(b, pt, std::forward<Args>(args)...). If an exception is thrown, the function has no effect.

    -?- Returns: A shared_ptr instance that stores and owns the address of the newly constructed object of type T. When ownership is given up, the effects are as follows: Uses a copy b2 of type A from a to destruct an object of type T by calling allocator_traits<A>::destroy(b2, pt2) where pt2 has type T* and refers to the newly constructed object. Then uses an object of type allocator_traits<A>::rebind_alloc<unspecified> that compares equal to a to deallocate the allocated memory.

    -?- Postconditions: get() != 0 && use_count() == 1

    -?- Throws: Nothing unless memory allocation or allocator_traits<A>::construct throws an exception.

    -?- Remarks: Implementations are encouraged, but not required, to perform no more than one memory allocation. [Note: Such an implementation provides efficiency equivalent to an intrusive smart pointer. — end note]

    -?- [Note: This function will typically allocate more memory than sizeof(T) to allow for internal bookkeeping structures such as the reference counts. — end note]


2077. Further incomplete constraints for type traits

Section: 20.10.4.3 [meta.unary.prop] Status: Open Submitter: Daniel Krügler Opened: 2011-08-20 Last modified: 2015-04-08

View other active issues in [meta.unary.prop].

View all other issues in [meta.unary.prop].

View all issues with Open status.

Discussion:

The currently agreed on proposed wording for 2015 using remove_all_extents<T>::type instead of the "an array of unknown bound" terminology in the precondition should be extended to some further entries especially in Table 49, notably the is_*constructible, is_*assignable, and is_*destructible entries. To prevent ODR violations, incomplete element types of arrays must be excluded for value-initialization and destruction for example. Construction and assignment has to be honored, when we have array-to-pointer conversions or pointer conversions of incomplete pointees in effect.

[2012, Kona]

The issue is that in three type traits, we are accidentally saying that in certain circumstances the type must give a specified answer when given an incomplete type. (Specifically: an array of unknown bound of incomplete type.) The issue asserts that there's an ODR violation, since the trait returns false in that case but might return a different version when the trait is completed.

Howard argues: no, there is no risk of an ODR violation. is_constructible<A[]> must return false regardless of whether A is complete, so there's no reason to forbid an array of unknown bound of incomplete types. Same argument applies to is_assignable. General agreement with Howard's reasoning.

There may be a real issue for is_destructible. None of us are sure what is_destructible is supposed to mean for an array of unknown bound (regardless of whether its type is complete), and the standard doesn't make it clear. The middle column doesn't say what it's supposed to do for incomplete types.

In at least one implementation, is_destructible<A[]> does return true if A is complete, which would result in ODR violation unless we forbid it for incomplete types.

Move to open. We believe there is no issue for is_constructible or is_assignable, but that there is a real issue for is_destructible.

Proposed resolution:


2088. std::terminate problem

Section: 18.8.3 [exception.terminate] Status: Open Submitter: Daniel Krügler Opened: 2011-09-25 Last modified: 2015-04-08

View all issues with Open status.

Discussion:

Andrzej Krzemienski reported the following on comp.std.c++:

In N3290, which is to become the official standard, in 18.8.3.4 [terminate], paragraph 1 reads

Remarks: Called by the implementation when exception handling must be abandoned for any of several reasons (15.5.1), in effect immediately after evaluating the throw-expression (18.8.3.1). May also be called directly by the program.

It is not clear what is "in effect". It was clear in previous drafts where paragraphs 1 and 2 read:

Called by the implementation when exception handling must be abandoned for any of several reasons (15.5.1). May also be called directly by the program.

Effects: Calls the terminate_handler function in effect immediately after evaluating the throw-expression (18.8.3.1), if called by the implementation, or calls the current terminate_handler function, if called by the program.

It was changed by N3189. The same applies to function unexpected (D. 11.4, paragraph 1).

Assuming the previous wording is still intended, the wording can be read "unless std::terminate is called by the program, we will use the handler that was in effect immediately after evaluating the throw-expression".

This assumes that there is some throw-expression connected to every situation that triggers the call to std::terminate. But this is not the case:

Which one is referred to?

In case std::nested_exception::rethrow_nested is called for an object that has captured no exception, there is no throw-expression involved directly (and may no throw be involved even indirectly).

Next, 18.8.3.1 [terminate.handler], paragraph 2 says

Required behavior: A terminate_handler shall terminate execution of the program without returning to the caller.

This seems to allow that the function may exit by throwing an exception (because word "return" implies a normal return).

One could argue that words "terminate execution of the program" are sufficient, but then why "without returning to the caller" would be mentioned. In case such handler throws, noexcept specification in function std::terminate is violated, and std::terminate would be called recursively - should std::abort not be called in case of recursive std::terminate call? On the other hand some controlled recursion could be useful, like in the following technique.

The here mentioned wording changes by N3189 in regard to 18.8.3.4 [terminate] p1 were done for a better separation of effects (Effects element) and additional normative wording explanations (Remarks element), there was no meaning change intended. Further, there was already a defect existing in the previous wording, which was not updated when further situations where defined, when std::terminate where supposed to be called by the implementation.

The part

"in effect immediately after evaluating the throw-expression"

should be removed and the quoted reference to 18.8.3.1 [terminate.handler] need to be part of the effects element where it refers to the current terminate_handler function, so should be moved just after

"Effects: Calls the current terminate_handler function."

It seems ok to allow a termination handler to exit via an exception, but the suggested idiom should better be replaced by a more simpler one based on evaluating the current exception pointer in the terminate handler, e.g.

void our_terminate (void) {
  std::exception_ptr p = std::current_exception();
  if (p) {
    ... // OK to rethrow and to determine it's nature
  } else {
    ... // Do something else
  }
}

[2011-12-09: Daniel comments]

A related issue is 2111.

[2012, Kona]

Move to Open.

There is an interaction with Core issues in this area that Jens is already supplying wording for. Review this issue again once Jens wording is available.

Alisdair to review clause 15.5 (per Jens suggestion) and recommend any changes, then integrate Jens wording into this issue.

Proposed resolution:


2089. std::allocator::construct should use uniform initialization

Section: 20.7.9.1 [allocator.members] Status: EWG Submitter: David Krauss Opened: 2011-10-07 Last modified: 2015-04-08

View all other issues in [allocator.members].

View all issues with EWG status.

Discussion:

When the EmplaceConstructible (23.2.1 [container.requirements.general]/13) requirement is used to initialize an object, direct-initialization occurs. Initializing an aggregate or using a std::initializer_list constructor with emplace requires naming the initialized type and moving a temporary. This is a result of std::allocator::construct using direct-initialization, not list-initialization (sometimes called "uniform initialization") syntax.

Altering std::allocator<T>::construct to use list-initialization would, among other things, give preference to std::initializer_list constructor overloads, breaking valid code in an unintuitive and unfixable way — there would be no way for emplace_back to access a constructor preempted by std::initializer_list without essentially reimplementing push_back.

std::vector<std::vector<int>> v;
v.emplace_back(3, 4); // v[0] == {4, 4, 4}, not {3, 4} as in list-initialization

The proposed compromise is to use SFINAE with std::is_constructible, which tests whether direct-initialization is well formed. If is_constructible is false, then an alternative std::allocator::construct overload is chosen which uses list-initialization. Since list-initialization always falls back on direct-initialization, the user will see diagnostic messages as if list-initialization (uniform-initialization) were always being used, because the direct-initialization overload cannot fail.

I can see two corner cases that expose gaps in this scheme. One occurs when arguments intended for std::initializer_list satisfy a constructor, such as trying to emplace-insert a value of {3, 4} in the above example. The workaround is to explicitly specify the std::initializer_list type, as in v.emplace_back(std::initializer_list<int>(3, 4)). Since this matches the semantics as if std::initializer_list were deduced, there seems to be no real problem here.

The other case is when arguments intended for aggregate initialization satisfy a constructor. Since aggregates cannot have user-defined constructors, this requires that the first nonstatic data member of the aggregate be implicitly convertible from the aggregate type, and that the initializer list have one element. The workaround is to supply an initializer for the second member. It remains impossible to in-place construct an aggregate with only one nonstatic data member by conversion from a type convertible to the aggregate's own type. This seems like an acceptably small hole.

The change is quite small because EmplaceConstructible is defined in terms of whatever allocator is specified, and there is no need to explicitly mention SFINAE in the normative text.

[2012, Kona]

Move to Open.

There appears to be a real concern with initializing aggregates, that can be performed only using brace-initialization. There is little interest in the rest of the issue, given the existence of 'emplace' methods in C++11.

Move to Open, to find an acceptable solution for intializing aggregates. There is the potential that EWG may have an interest in this area of language consistency as well.

[2013-10-13, Ville]

This issue is related to 2070.

[2015-02 Cologne]

Move to EWG, Ville to write a paper.

Proposed resolution:

This wording is relative to the FDIS.

Change 20.7.9.1 [allocator.members] p12 as indicated:

template <class U, class... Args>
  void construct(U* p, Args&&... args);

12 Effects: ::new((void *)p) U(std::forward<Args>(args)...) if is_constructible<U, Args...>::value is true, else ::new((void *)p) U{std::forward<Args>(args)...}


2095. promise and packaged_task missing constructors needed for uses-allocator construction

Section: 30.6.5 [futures.promise], 30.6.9 [futures.task] Status: Open Submitter: Jonathan Wakely Opened: 2011-11-01 Last modified: 2015-04-08

View other active issues in [futures.promise].

View all other issues in [futures.promise].

View all issues with Open status.

Discussion:

This example is ill-formed according to C++11 because uses_allocator<promise<R>, A>::value is true, but is_constructible<promise<R>, A, promise<R>&&>::value is false. Similarly for packaged_task.

#include <future>
#include <memory>
#include <tuple>

using namespace std;

typedef packaged_task<void()> task;
typedef promise<void> prom;
allocator<task> a;

tuple<task, prom> t1{ allocator_arg, a };
tuple<task, prom> t2{ allocator_arg, a, task{}, prom{} };

[2012, Portland]

This is an allocator issue, and should be dealt with directly by LWG.

[2013-03-06]

Jonathan suggests to make the new constructors non-explicit and makes some representational improvements.

[2013-09 Chicago]

Move to deferred.

This issue has much in common with similar problems with std::function that are being addressed by the polymorphic allocators proposal currently under evaluation in LEWG. Defer further discussion on this topic until the final outcome of that paper and its proposed resolution is known.

[2014-02-20 Re-open Deferred issues as Priority 4]

Proposed resolution:

[This wording is relative to the FDIS.]

  1. Add to 30.6.5 [futures.promise], class template promise synopsis, as indicated:

    namespace std {
      template <class R>
      class promise {
      public:
        promise();
        template <class Allocator>
        promise(allocator_arg_t, const Allocator& a);
        template <class Allocator>
        promise(allocator_arg_t, const Allocator& a, promise&& rhs) noexcept;
        promise(promise&& rhs) noexcept;
        promise(const promise& rhs) = delete;
        ~promise();	
        […]
      };
      […]
    }
    
  2. Change 30.6.5 [futures.promise] as indicated:

    promise(promise&& rhs) noexcept;
    template <class Allocator>
    promise(allocator_arg_t, const Allocator& a, promise&& rhs) noexcept;
    

    -5- Effects: constructs a new promise object and transfers ownership of the shared state of rhs (if any) to the newly-constructed object.

    -6- Postcondition: rhs has no shared state.

    -?- [Note: a is not used — end note]

  3. Add to 30.6.9 [futures.task], class template packaged_task synopsis, as indicated:

    namespace std {
      template<class> class packaged_task; // undefined
    
      template<class R, class... ArgTypes>
      class packaged_task<R(ArgTypes...)> {
      public:
        // construction and destruction
        packaged_task() noexcept;
        template <class Allocator>
          packaged_task(allocator_arg_t, const Allocator& a) noexcept;
        template <class F>
          explicit packaged_task(F&& f);
        template <class F, class Allocator>
          explicit packaged_task(allocator_arg_t, const Allocator& a, F&& f);
        ~packaged_task();
    	
        // no copy
        packaged_task(const packaged_task&) = delete;
        template<class Allocator>
          packaged_task(allocator_arg_t, const Allocator& a, const packaged_task&) = delete;
        packaged_task& operator=(const packaged_task&) = delete;
        
        // move support
        packaged_task(packaged_task&& rhs) noexcept;
        template <class Allocator>
          packaged_task(allocator_arg_t, const Allocator& a, packaged_task&& rhs) noexcept;
        packaged_task& operator=(packaged_task&& rhs) noexcept;
        void swap(packaged_task& other) noexcept;
        […]
      };
      […]
    }
    
  4. Change 30.6.9.1 [futures.task.members] as indicated:

    packaged_task() noexcept;
    template <class Allocator>
      packaged_task(allocator_arg_t, const Allocator& a) noexcept;
    

    -1- Effects: constructs a packaged_task object with no shared state and no stored task.

    -?- [Note: a is not used — end note]

    […]

    packaged_task(packaged_task&& rhs) noexcept;
    template <class Allocator>
      packaged_task(allocator_arg_t, const Allocator& a, packaged_task&& rhs) noexcept;
    

    -5- Effects: constructs a new packaged_task object and transfers ownership of rhs's shared state to *this, leaving rhs with no shared state. Moves the stored task from rhs to *this.

    -6- Postcondition: rhs has no shared state.

    -?- [Note: a is not used — end note]


2114. Incorrect "contextually convertible to bool" requirements

Section: 17.6.3.3 [nullablepointer.requirements], 24.2.3 [input.iterators], 24.2.7 [random.access.iterators], 25.1 [algorithms.general], 25.4 [alg.sorting], 30.2.1 [thread.req.paramname] Status: Open Submitter: Daniel Krügler Opened: 2011-12-09 Last modified: 2015-05-22

View all issues with Open status.

Discussion:

As of 17.6.3.1 [utility.arg.requirements] Table 17/18, the return types of the expressions

a == b

or

a < b

for types satisfying the EqualityComparable or LessThanComparable types, respectively, are required to be "convertible to bool" which corresponds to a copy-initialization context. But several newer parts of the library that refer to such contexts have lowered the requirements taking advantage of the new terminology of "contextually convertible to bool" instead, which corresponds to a direct-initialization context (In addition to "normal" direct-initialization constructions, operands of logical operations as well as if or switch conditions also belong to this special context).

One example for these new requirements are input iterators which satisfy EqualityComparable but also specify that the expression

a != b

shall be just "contextually convertible to bool". The same discrepancy exists for requirement set NullablePointer in regard to several equality-related expressions.

For random access iterators we have

a < b contextually convertible to bool

as well as for all derived comparison functions, so strictly speaking we could have a random access iterator that does not satisfy the LessThanComparable requirements, which looks like an artifact to me.

Even if we keep with the existing requirements based on LessThanComparable or EqualityComparable we still would have the problem that some current specifications are actually based on the assumption of implicit convertibility instead of "explicit convertibility", e.g. 20.8.1.5 [unique.ptr.special] p3:

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

-3- Returns: x.get() != y.get().

Similar examples exist in 20.8.1.2.2 [unique.ptr.single.dtor] p2, 20.8.1.2.3 [unique.ptr.single.asgn] p9, 20.8.1.2.4 [unique.ptr.single.observers] p1+3+8, etc.

In all these places the expressions involving comparison functions (but not those of the conversion of a NullablePointer to bool!) assume to be "convertible to bool". I think this is a very natural assumption and all delegations of the comparison functions of some type X to some other API type Y in third-party code does so assuming that copy-initialization semantics will just work.

The actual reason for using the newer terminology can be rooted back to LWG 556. My hypotheses is that the resolution of that issue also needs a slight correction. Why so?

The reason for opening that issue were worries based on the previous "convertible to bool" wording. An expressions like "!pred(a, b)" might not be well-formed in those situations, because operator! might not be accessible or might have an unusual semantics (and similarly for other logical operations). This can indeed happen with unusual proxy return types, so the idea was that the evaluation of Predicate, BinaryPredicate (25.1 [algorithms.general] p8+9), and Compare (25.4 [alg.sorting] p2) should be defined based on contextual conversion to bool. Unfortunately this alone is not sufficient: In addition, I think, we also want the predicates to be (implicitly) convertible to bool! Without this wording, several conditions are plain wrong, e.g. 25.2.5 [alg.find] p2, which talks about "pred(*i) != false" (find_if) and "pred(*i) == false" (find_if_not). These expressions are not within a boolean context!

While we could simply fix all these places by proper wording to be considered in a "contextual conversion to bool", I think that this is not the correct solution: Many third-party libraries already refer to the previous C++03 Predicate definition — it actually predates C++98 and is as old as the SGI specification. It seems to be a high price to pay to switch to direct initialization here instead of fixing a completely different specification problem.

A final observation is that we have another definition for a Predicate in 30.2.1 [thread.req.paramname] p2:

If a parameter is Predicate, operator() applied to the actual template argument shall return a value that is convertible to bool.

The problem here is not that we have two different definitions of Predicate in the standard — this is confusing, but this fact alone is not a defect. The first (minor) problem is that this definition does not properly apply to function objects that are function pointers, because operator() is not defined in a strict sense. But the actually worse second problem is that this wording has the very same problem that has originally lead to LWG 556! We only need to look at 30.5.1 [thread.condition.condvar] p15 to recognice this:

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

The negation expression here looks very familiar to the example provided in LWG 556 and is sensitive to the same "unusual proxy" problem. Changing the 30.2.1 [thread.req.paramname] wording to a corresponding "contextual conversion to bool" wouldn't work either, because existing specifications rely on "convertible to bool", e.g. 30.5.1 [thread.condition.condvar] p32+33+42 or 30.5.2 [thread.condition.condvarany] p25+26+32+33.

To summarize: I believe that LWG 556 was not completely resolved. A pessimistic interpretation is, that even with the current wording based on "contextually convertible to bool" the actual problem of that issue has not been fixed. What actually needs to be required here is some normative wording that basically expresses something along the lines of:

The semantics of any contextual conversion to bool shall be equivalent to the semantics of any implicit conversion to bool.

This is still not complete without having concepts, but it seems to be a better approximation. Another way of solving this issue would be to define a minimum requirements table with equivalent semantics. The proposed wording is a bit simpler but attempts to express the same thing.

[2012, Kona]

Agree with Daniel that we potentially broke some C++03 user code, accept the changes striking "contextually" from tables. Stefan to provide revised wording for section 25, and figure out changes to section 30.

Move to open, and then to Review when updated wording from Stefan is available.

[2012-10-12, STL comments]

  1. The current proposed resolution still isn't completely satisfying. It would certainly be possible for the Standard to require these various expressions to be implicitly and contextually convertible to bool, but that would have a subtle consequence (which, I will argue, is undesirable - regardless of the fact that it dates all the way back to C++98/03). It would allow users to provide really wacky types to the Standard Library, with one of two effects:

    1. Standard Library implementations would have to go to great lengths to respect such wacky types, essentially using static_cast<bool> when invoking any predicates or comparators.

    2. Otherwise, such wacky types would be de facto nonportable, because they would make Standard Library implementations explode.

    Effect B is the status quo we're living with today. What Standard Library implementations want to do with pred(args) goes beyond "if (pred(args))" (C++03), contextually converting pred(args) to bool (C++11), or implicitly and contextually converting pred(args) to bool (the current proposed resolution). Implementations want to say things like:

    if (pred(args))
    if (!pred(args))
    if (cond && pred(args))
    if (cond && !pred(args))
    

    These are real examples taken from Dinkumware's implementation. There are others that would be realistic ("pred(args) && cond", "cond || pred(args)", etc.)

    Although negation was mentioned in this issue's Discussion section, and in LWG 556's, the current proposed resolution doesn't fix this problem. Requiring pred(args) to be implicitly and contextually convertible to bool doesn't prevent operator!() from being overloaded and returning std::string (as a wacky example). More ominously, it doesn't prevent operator&&() and operator||() from being overloaded and destroying short-circuiting.

  2. I would like LWG input before working on Standardese for a new proposed resolution. Here's an outline of what I'd like to do:

    1. Introduce a new "concept" in 17.6.3 [utility.requirements], which I would call BooleanTestable in the absence of better ideas.

    2. Centralize things and reduce verbosity by having everything simply refer to BooleanTestable when necessary. I believe that the tables could say "Return type: BooleanTestable", while Predicate/BinaryPredicate/Compare would need the incantation "shall satisfy the requirements of BooleanTestable".

    3. Resolve the tug-of-war between users (who occasionally want to do weird things) and implementers (who don't want to have to contort their code) by requiring that:

      1. Given a BooleanTestable x, x is both implicitly and contextually convertible to bool.

      2. Given a BooleanTestable x, !x is BooleanTestable. (This is intentionally "recursive".)

      3. Given a BooleanTestable x, bool t = x, t2(x), f = !x; has the postcondition t == t2 && t != f.

      4. Given a BooleanTestable x and a BooleanTestable y of possibly different types, "x && y" and "x || y" invoke the built-in operator&&() and operator||(), triggering short-circuiting.

      5. bool is BooleanTestable.

    I believe that this simultaneously gives users great latitude to use types other than bool, while allowing implementers to write reasonable code in order to get their jobs done. (If I'm forgetting anything that implementers would want to say, please let me know.)

  3. About requirement (I): As Daniel patiently explained to me, we need to talk about both implicit conversions and contextual conversions, because it's possible for a devious type to have both "explicit operator bool()" and "operator int()", which might behave differently (or be deleted, etc.).

  4. About requirement (IV): This is kind of tricky. What we'd like to say is, "BooleanTestable can't ever trigger an overloaded logical operator". However, given a perfectly reasonable type Nice - perhaps even bool itself! - other code (perhaps a third-party library) could overload operator&&(Nice, Evil). Therefore, I believe that the requirement should be "no first use" - the Standard Library will ask for various BooleanTestable types from users (for example, the result of "first != last" and the result of "pred(args)"), and as long as they don't trigger overloaded logical operators with each other, everything is awesome.

  5. About requirement (V): This is possibly redundant, but it's trivial to specify, makes it easier for users to understand what they need to do ("oh, I can always achieve this with bool"), and provides a "base case" for requirement (IV) that may or may not be necessary. Since bool is BooleanTestable, overloading operator&&(bool, Other) (etc.) clearly makes the Other type non-BooleanTestable.

Previous resolution from Daniel [SUPERSEDED]:

This wording is relative to the FDIS.

  1. Change Table 25 — "NullablePointer requirements" in 17.6.3.3 [nullablepointer.requirements] as indicated:

    Table 25 — NullablePointer requirements
    Expression Return type Operational semantics
    […]
    a != b contextually convertible to bool !(a == b)
    a == np
    np == a
    contextually convertible to bool a == P()
    a != np
    np != a
    contextually convertible to bool !(a == np)
  2. Change Table 107 — "Input iterator requirements" in 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 ==.
    […]
  3. Change Table 111 — "Random access iterator requirements" in 24.2.7 [random.access.iterators] as indicated:

    Table 111 — Random access iterator requirements (in addition to bidirectional iterator)
    Expression Return type Operational semantics Assertion/note
    pre-/post-condition
    […]
    a < b contextually convertible to bool b - a > 0 < is a total ordering relation
    a > b contextually convertible to bool b < a > is a total ordering relation opposite to <.
    a >= b contextually convertible to bool !(a < b)
    a <= b contextually convertible to bool !(a > b)
  4. Change 25.1 [algorithms.general] p8+9 as indicated:

    -8- The Predicate parameter is used whenever an algorithm expects a function object (20.9 [function.objects]) that, when applied to the result of dereferencing the corresponding iterator, returns a value testable as true. In other words, if an algorithm takes Predicate pred as its argument and first as its iterator argument, it should work correctly in the construct pred(*first) implicitly or contextually converted to bool (Clause 4 [conv]). The function object pred shall not apply any non-constant function through the dereferenced iterator.

    -9- The BinaryPredicate parameter is used whenever an algorithm expects a function object that when applied to the result of dereferencing two corresponding iterators or to dereferencing an iterator and type T when T is part of the signature returns a value testable as true. In other words, if an algorithm takes BinaryPredicate binary_pred as its argument and first1 and first2 as its iterator arguments, it should work correctly in the construct binary_pred(*first1, *first2) implicitly or contextually converted to bool (Clause 4 [conv]). BinaryPredicate always takes the first iterator's value_type as its first argument, that is, in those cases when T value is part of the signature, it should work correctly in the construct binary_pred(*first1, value) implicitly or contextually converted to bool (Clause 4 [conv]). binary_pred shall not apply any non-constant function through the dereferenced iterators.

  5. Change 25.4 [alg.sorting] p2 as indicated:

    -2- Compare is a function object type (20.9 [function.objects]). The return value of the function call operation applied to an object of type Compare, when implicitly or contextually converted to bool (4 [conv]), yields true if the first argument of the call is less than the second, and false otherwise. Compare comp is used throughout for algorithms assuming an ordering relation. It is assumed that comp will not apply any non-constant function through the dereferenced iterator.

  6. Change 30.2.1 [thread.req.paramname] p2 as indicated:

    -2- If a parameter is Predicate, operator() applied to the actual template argument shall return a value that is convertible to boolPredicate is a function object type (20.9 [function.objects]). The return value of the function call operation applied to an object of type Predicate, when implicitly or contextually converted to bool (4 [conv]), yields true if the corresponding test condition is satisfied, and false otherwise.

[2014-05-20, Daniel suggests concrete wording based on STL's proposal]

The presented wording follows relatively closely STL's outline with the following notable exceptions:

  1. A reference to BooleanTestable in table "Return Type" specifications seemed very unusual to me and I found no "prior art" for this in the Standard. Instead I decided to follow the usual style to add a symbol with a specific meaning to a specific paragraph that specifies symbols and their meanings.

  2. STL's requirement IV suggested to directly refer to built-in operators && and ||. In my opinion this concrete requirement isn't needed if we simply require that two BooleanTestable operands behave equivalently to two those operands after conversion to bool (each of them).

  3. I couldn't find a good reason to require normatively that type bool meets the requirements of BooleanTestable: My assertion is that after having defined them, the result simply falls out of this. But to make this a bit clearer, I added also a non-normative note to these effects.

[2014-06-10, STL comments]

In the current wording I would like to see changed the suggested changes described by bullet #6:

  1. In 23.2.1 [container.requirements.general] p4 undo the suggested change

  2. Then change the 7 occurrences of "convertible to bool" in the denoted tables to "bool".

[2015-05-05 Lenexa]

STL: Alisdair wanted to do something here, but Daniel gave us updated wording.

Proposed resolution:

This wording is relative to N3936.

  1. Change 17.6.3.1 [utility.arg.requirements] p1, Table 17 — "EqualityComparable requirements", and Table 18 — "LessThanComparable requirements" as indicated:

    -1- […] In these tables, T is an object or reference type to be supplied by a C++ program instantiating a template; a, b, and c are values of type (possibly const) T; s and t are modifiable lvalues of type T; u denotes an identifier; rv is an rvalue of type T; and v is an lvalue of type (possibly const) T or an rvalue of type const T; and BT denotes a type that meets the BooleanTestable requirements ([booleantestable.requirements]).

    […]

    Table 17 — EqualityComparable requirements [equalitycomparable]
    Expression Return type Requirement
    a == b convertible to
    bool
    BT
    == is an equivalence relation, that is, it has the following properties: […]

    […]

    Table 18 — LessThanComparable requirements [lessthancomparable]
    Expression Return type Requirement
    a < b convertible to
    bool
    BT
    < is a strict weak ordering relation (25.4 [alg.sorting])
  2. Between 17.6.3.2 [swappable.requirements] and 17.6.3.3 [nullablepointer.requirements] insert a new sub-clause as indicated:

    ?.?.?.? BooleanTestable requirements [booleantestable.requirements]

    -?- A BooleanTestable type is a boolean-like type that also supports conversions to bool. A type B meets the BooleanTestable requirements if the expressions described in Table ?? are valid and have the indicated semantics, and if B also satisfies all the other requirements of this sub-clause [booleantestable.requirements].

    An object b of type B can be implicitly converted to bool and can be contextually converted to bool (Clause 4). The result values of both kinds of conversions shall be equivalent.

    [Example: The types bool, std::true_type, and std::bitset<>::reference are BooleanTestable types. — end example]

    In Table ??, B2 and Bn denote types (possibly equal to B or to each other) that meet the BooleanTestable requirements, b1 denotes a (possibly const) value of B, b2 denotes a (possibly const) value of B2, and t1 denotes a value of type bool.

  3. Somewhere within the new sub-clause [booleantestable.requirements] insert the following new Table (?? denotes the assigned table number):

    Table ?? — BooleanTestable requirements [booleantestable]
    Expression Return type Operational semantics
    bool(b1) bool Remarks: bool(b1) == t1 for every value
    b1 implicitly converted to t1.
    !b1 Bn Remarks: bool(b1) == !bool(!b1) for
    every value b1.
    b1 && b2 bool bool(b1) && bool(b2)
    b1 || b2 bool bool(b1) || bool(b2)
  4. Change 17.6.3.3 [nullablepointer.requirements] p5 and Table 25 — "NullablePointer requirements" as indicated:

    […]

    -5- In Table 25, u denotes an identifier, t denotes a non-const lvalue of type P, a and b denote values of type (possibly const) P, and np denotes a value of type (possibly const) std::nullptr_t, and BT denotes a type that meets the BooleanTestable requirements ([booleantestable.requirements]).

    […]

    Table 25 — NullablePointer requirements [nullablepointer]
    Expression Return type Operational semantics
    a != b contextually convertible to boolBT […]
    a == np
    np == a
    contextually convertible to boolBT […]
    a != np
    np != a
    contextually convertible to boolBT […]
  5. Change 20.4.2.7 [tuple.rel] as indicated;

    template<class... TTypes, class... UTypes>
    constexpr bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u);
    

    -1- Requires: For all i, where 0 <= i and i < sizeof...(TTypes), get<i>(t) == get<i>(u) is a valid expression returning a type that is convertible to boolmeets the BooleanTestable requirements ([booleantestable.requirements]). sizeof...(TTypes) == sizeof...(UTypes).

    […]

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

    -4- Requires: For all i, where 0 <= i and i < sizeof...(TTypes), get<i>(t) < get<i>(u) and get<i>(u) < get<i>(t) are valid expressions returning types that are convertible to boolmeet the BooleanTestable requirements ([booleantestable.requirements]). sizeof...(TTypes) == sizeof...(UTypes).

    […]

  6. Change 23.2.1 [container.requirements.general], Table 96 — "Container requirements", and Table 98 — "Optional container operations" as indicated:

    -4- In Tables 96, 97, and 98 X denotes a container class containing objects of type T, a and b denote values of type X, u denotes an identifier, r denotes a non-const value of type X, and rv denotes a non-const rvalue of type X, and BT denotes a type that meets the BooleanTestable requirements ([booleantestable.requirements]).

    Table 96 — Container requirements
    Expression Return type […]
    a == b convertible to
    bool
    BT
    […]
    a != b convertible to
    bool
    BT
    […]
    a.empty() convertible to
    bool
    BT
    […]

    […]

    Table 98 — Optional container requirements
    Expression Return type […]
    a < b convertible to
    bool
    BT
    […]
    a > b convertible to
    bool
    BT
    […]
    a <= b convertible to
    bool
    BT
    […]
    a >= b convertible to
    bool
    BT
    […]
  7. Change 24.2.1 [iterator.requirements.general], Table 107 — "Input iterator requirements", and Table 111 — "Random access iterator requirements" as indicated:

    -11- In the following sections, a and b denote values of type X or const X, difference_type and reference refer to the types iterator_traits<X>::difference_type and iterator_traits<X>::reference, respectively, n denotes a value of difference_type, u, tmp, and m denote identifiers, r denotes a value of X&, t denotes a value of value type T, o denotes a value of some type that is writable to the output iterator, and BT denotes a type that meets the BooleanTestable requirements ([booleantestable.requirements]).

    Table 107 — Input iterator requirements
    Expression Return type […]
    a != b contextually convertible to
    bool
    BT
    […]

    […]

    Table 111 — Random access iterator requirements
    Expression Return type […]
    a < b contextually convertible to
    bool
    BT
    […]
    a > b contextually convertible to
    bool
    BT
    […]
    a >= b contextually convertible to
    bool
    BT
    […]
    a <= b contextually convertible to
    bool
    BT
    […]
  8. Change 25.1 [algorithms.general] p8+p9 as indicated: [Drafting note: The wording change also fixes (a) unusual wording forms used ("should work") which are unclear in which sense they are imposing normative requirements and (b) the problem, that the current wording seems to allow that the predicate may mutate a call argument, if that is not a dereferenced iterator. Upon applying the new wording it became obvious that the wording has the effect that currently algorithms such as adjacent_find, search_n, unique, and unique_copy are not correctly described (because they have no iterator argument named first1), which could give raise to a new library issue. — end drafting note]

    -8- The Predicate parameter is used whenever an algorithm expects a function object (20.9) that, when applied to the result of dereferencing the corresponding iterator, returns a value testable as true. In other words, iIf an algorithm takes Predicate pred as its argument and first as its iterator argument, it should work correctly in the construct pred(*first) contextually converted to bool (Clause 4)the expression pred(*first) shall have a type that meets the BooleanTestable requirements ( [booleantestable.requirements]). The function object pred shall not apply any non-constant function through the dereferenced iteratorits argument.

    -9- The BinaryPredicate parameter is used whenever an algorithm expects a function object that when applied to the result of dereferencing two corresponding iterators or to dereferencing an iterator and type T when T is part of the signature returns a value testable as true. In other words, iIf an algorithm takes BinaryPredicate binary_pred as its argument and first1 and first2 as its iterator arguments, it should work correctly in the construct binary_pred(*first1, *first2) contextually converted to bool (Clause 4)the expression binary_pred(*first1, *first2) shall have a type that meets the BooleanTestable requirements ( [booleantestable.requirements]). BinaryPredicate always takes the first iterator's value_type as its first argument, that is, in those cases when T value is part of the signature, it should work correctly in the construct binary_pred(*first1, value) contextually converted to bool (Clause 4)the expression binary_pred(*first1, value) shall have a type that meets the BooleanTestable requirements ( [booleantestable.requirements]). binary_pred shall not apply any non-constant function through the dereferenced iteratorsany of its arguments.

  9. Change 25.4 [alg.sorting] p2 as indicated:

    […]

    -2- Compare is a function object type (20.9). The return value of the function call operation applied to an object of type Compare, when contextually converted to bool(Clause 4), yields true if the first argument of the call is less than the second, and false otherwise. Compare comp is used throughout for algorithms assuming an ordering relation. Let a and b denote two argument values whose types depend on the corresponding algorithm. Then the expression comp(a, b) shall have a type that meets the BooleanTestable requirements ( [booleantestable.requirements]). The return value of comp(a, b), converted to bool, yields true if the first argument a is less than the second argument b, and false otherwise. It is assumed that comp will not apply any non-constant function through the dereferenced iteratorany of its arguments.

    […]

  10. Change 27.5.4.2 [fpos.operations] and Table 127 — "Position type requirements" as indicated:

    -1- Operations specified in Table 127 are permitted. In that table,

    • P refers to an instance of fpos,

    • […]

    • o refers to a value of type streamoff,

    • BT refers to a type that meets the BooleanTestable requirements ([booleantestable.requirements]),

    • […]

    Table 127 — Position type requirements
    Expression Return type […]
    p == q convertible to boolBT […]
    p != q convertible to boolBT […]
  11. Change 30.2.1 [thread.req.paramname] p2 as indicated:

    -2- If a parameter is Predicate, operator() applied to the actual template argument shall return a value that is convertible to boolPredicate is a function object type (20.9 [function.objects]). Let pred denote an lvalue of type Predicate. Then the expression pred() shall have a type that meets the BooleanTestable requirements ( [booleantestable.requirements]). The return value of pred(), converted to bool, yields true if the corresponding test condition is satisfied, and false otherwise.


2115. Undefined behaviour for valarray assignments with mask_array index?

Section: 26.6.8 [template.mask.array] Status: Open Submitter: Thomas Plum Opened: 2011-12-10 Last modified: 2015-04-08

View all issues with Open status.

Discussion:

Recently I received a Service Request (SR) alleging that one of our testcases causes an undefined behavior. The complaint is that 26.6.8 [template.mask.array] in C++11 (and the corresponding subclause in C++03) are interpreted by some people to require that in an assignment "a[mask] = b", the subscript mask and the rhs b must have the same number of elements.

IMHO, if that is the intended requirement, it should be stated explicitly.

In any event, there is a tiny editorial cleanup that could be made:

In C++11, 26.6.8.1 [template.mask.array.overview] para 2 mentions

"the expression a[mask] = b;"

but the semicolon cannot be part of an expression. The correction could omit the semicolon, or change the word "expression" to "assignment" or "statement".

Here is the text of the SR, slightly modified for publication:

Subject: SR01174 LVS _26322Y31 has undefined behavior [open]

[Client:]
The test case t263.dir/_26322Y31.cpp seems to be illegal as it has an undefined behaviour. I searched into the SRs but found SRs were not related to the topic explained in this mail (SR00324, SR00595, SR00838).

const char vl[] = {"abcdefghijklmnopqrstuvwxyz"};
const char vu[] = {"ABCDEFGHIJKLMNOPQRSTUVWXYZ"};
const std::valarray<char> v0(vl, 27), vm5(vu, 5), vm6(vu, 6);
std::valarray<char> x = v0;
[…]
const bool vb[] = {false, false, true, true, false, true};
const std::valarray<bool> vmask(vb, 6);
x = v0;
x[vmask] = vm5;      // ***** HERE....
steq(&x[0], "abABeCghijklmnopqrstuvwxyz");
x2 = x[vmask];       // ***** ....AND HERE
[…]

This problem has already been discussed between [experts]: See thread http://gcc.gnu.org/ml/libstdc++/2009-11/threads.html#00051 Conclusion http://gcc.gnu.org/ml/libstdc++/2009-11/msg00099.html

[Plum Hall:]
Before I log this as an SR, I need to check one detail with you.

I did read the email thread you mentioned, and I did find a citation (see INCITS ISO/IEC 14882-2003 Section 26.3.2.6 on valarray computed assignments):

Quote: "If the array and the argument array do not have the same length, the behavior is undefined",

But this applies to computed assignment (*=, +=, etc), not to simple assignment. Here is the C++03 citation re simple assignment:

26.3.2.2 valarray assignment [lib.valarray.assign]

valarray<T>& operator=(const valarray<T>&);

1 Each element of the *this array is assigned the value of the corresponding element of the argument array. The resulting behavior is undefined if the length of the argument array is not equal to the length of the *this array.

In the new C++11 (N3291), we find ...

26.6.2.3 valarray assignment [valarray.assign]

valarray<T>& operator=(const valarray<T>& v);

1 Each element of the *this array is assigned the value of the corresponding element of the argument array. If the length of v is not equal to the length of *this, resizes *this to make the two arrays the same length, as if by calling resize(v.size()), before performing the assignment.

So it looks like the testcase might be valid for C++11 but not for C++03; what do you think?

[Client:]
I quite agree with you but the two problems I mentioned:

x[vmask] = vm5;      // ***** HERE....
[…]
x2 = x[vmask];       // ***** ....AND HERE

refer to mask_array assignment hence target the C++03 26.3.8 paragraph. Correct?

[Plum Hall:]
I mentioned the contrast between C++03 26.3.2.2 para 1 versus C++11 26.6.2.3 para 1.

But in C++03 26.3.8, I don't find any corresponding restriction. Could you quote the specific requirement you're writing about?

[Client:]
I do notice the difference between c++03 26.3.2.2 and c++11 26.6.2.3 about assignments between different sized valarray and I perfectly agree with you.

But, as already stated, this is not a simple valarray assignment but a mask_array assignment (c++03 26.3.8 / c++11 26.6.8). See c++11 quote below:

26.6.8 Class template mask_array
26.6.8.1 Class template mask_array overview
[....]

  1. This template is a helper template used by the mask subscript operator: mask_array<T> valarray<T>::operator[](const valarray<bool>&).

  2. It has reference semantics to a subset of an array specified by a boolean mask. Thus, the expression a[mask] = b; has the effect of assigning the elements of b to the masked elements in a (those for which the corresponding element in mask is true.)

26.6.8.2 mask_array assignment

void operator=(const valarray<T>&) const;
const mask_array& operator=(const mask_array&) const;

1 These assignment operators have reference semantics, assigning the values of the argument array elements to selected elements of the valarray<T> object to which it refers.

In particular, [one of the WG21 experts] insisted on the piece "the elements of b".

That is why I reported the test t263.dir/_26322Y31.cpp having an undefined behaviour.

[Plum Hall:]
OK, I can see that I will have to ask WG21; I will file an appropriate issue with the Library subgroup. In the meantime, I will mark this testcase as "DISPUTED" so that it is not required for conformance testing, until we get a definitive opinion.

[2012, Kona]

Moved to Open.

There appears to be a real need for clarification in the standard, and implementations differ in their current interpretation. This will need some research by implementers and a proposed resolution before further discussion is likely to be fruitful.

Proposed resolution:


2116. std::swap noexcept(what?)

Section: 20.10.4.3 [meta.unary.prop] Status: Open Submitter: Dave Abrahams Opened: 2011-12-09 Last modified: 2015-04-08

View other active issues in [meta.unary.prop].

View all other issues in [meta.unary.prop].

View all issues with Open status.

Discussion:

IMO if we specified is_[nothrow_]constructible in terms of a variable declaration whose validity requires destructibility, it is clearly a bug in our specification and a failure to realize the actual original intent. The specification should have been in terms of placement-new.

Daniel:
At the time of the specification this was intended and the solution is not done by removing the destruction semantics of is_constructible.

The design of is_constructible was also impacted by the previous Constructible concept that explicitly contained destruction semantics, because during conceptification of the library it turned out to simplify the constraints in the library because you did not need to add Destructible all the time. It often was implied but never spoken out in C++03.

Pure construction semantics was considered as useful as well, so HasConstructor did also exist and would surely be useful as trait as well.

Another example that is often overlooked: This also affects wrapper types like pair, tuple, array that contain potentially more than one type: This is easy to understand if you think of T1 having a deleted destructor and T2 having a constructor that may throw: Obviously the compiler has potentially need to use the destructor of T1 in the constructor of std::pair<T1, T2> to ensure that the core language requirements are satisfied (All previous fully constructed sub-objects must be destructed).

The core language also honors this fact in 12.8 [class.copy] p11:

A defaulted copy/move constructor for a class X is defined as deleted (8.4.3 [dcl.fct.def.delete]) if X has:
[…]
— any direct or virtual base class or non-static data member of a type with a destructor that is deleted or inaccessible from the defaulted constructor,
[…]

Dave:
This is about is_nothrow_constructible in particular. The fact that it is foiled by not having a noexcept dtor is a defect.

[2012, Kona]

Move to Open.

is_nothrow_constructible is defined in terms of is_constructible, which is defined by looking at a hypothetical variable and asking whether the variable definition is known not to throw exceptions. The issue claims that this also examines the type's destructor, given the context, and thus will return false if the destructor can potentially throw. At least one implementation (Howard's) does return false if the constructor is noexcept(true) and the destructor is noexcept(false). So that's not a strained interpretation. The issue is asking for this to be defined in terms of placement new, instead of in terms of a temporary object, to make it clearer that is_nothrow_constructible looks at the noexcept status of only the constructor, and not the destructor.

Sketch of what the wording would look like:

require is_constructible, and then also require that a placement new operation does not throw. (Remembering the title of this issue... What does this imply for swap?

If we accept this resolution, do we need any changes to swap?

STL argues: no, because you are already forbidden from passing anything with a throwing desturctor to swap.

Dietmar argues: no, not true. Maybe statically the destructor can conceivably throw for some values, but maybe there are some values known not to throw. In that case, it's correct to pass those values to swap.

Proposed resolution:


2117. ios_base manipulators should have showgrouping/noshowgrouping

Section: 22.4.2.2.2 [facet.num.put.virtuals], 27.5.3.1.2 [ios::fmtflags], 27.5.6.1 [fmtflags.manip] Status: New Submitter: Benjamin Kosnik Opened: 2011-12-15 Last modified: 2015-04-08

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

View all issues with New status.

Discussion:

Iostreams should include a manipulator to toggle grouping on/off for locales that support grouped digits. This has come up repeatedly and been deferred. See LWG 826 for the previous attempt.

If one is using a locale that supports grouped digits, then output will always include the generated grouping characters. However, very plausible scenarios exist where one might want to output the number, un-grouped. This is similar to existing manipulators that toggle on/off the decimal point, numeric base, or positive sign.

See some user commentary here.

[21012, Kona]

Move to Open.

This is a feature request.

Walter is slightly uncomfortable with processing feature requests through the issues lists.

Alisdair says this is far from the first feature request that has come in from the issues list.

STL: The fact that you can turn off grouping on hex output is compelling.

Marshall: if we add this flag, we'll need to update tables 87-91 as well.

STL: If it has been implemented somewhere, and it works, we'd be glad to add it.

Howard: We need to say what the default is.

Alisdair sumarizes:

(1) We want clear wording that says what the effect is of turning the flag off;

(2) what the default values are, and

(3) how this fits into tables 87-90. (and 128)

[Issaquah 2014-02-10-12: Move to LEWG]

Since this issue was filed, we have grown a new working group that is better placed to handle feature requests.

We will track such issues with an LEWG status until we get feedback from the Library Evolution Working Group.

[Issaquah 2014-02-12: LEWG discussion]

Do we think this feature should exist?
SFFNASA
2 4100

Think about the ABI break for adding a flag. But this could be mitigated by putting the data into an iword instead of a flag.

This needs to change Stage 2 in [facet.num.put.virtuals].

Previous resolution, which needs the above corrections:

This wording is relative to the FDIS.

  1. Insert in 22.4.2.2.2 [facet.num.put.virtuals] paragraph 5:

    Stage 1: The first action of stage 1 is to determine a conversion specifier. The tables that describe this determination use the following local variables

    fmtflags flags = str.flags() ;
    fmtflags basefield = (flags & (ios_base::basefield));
    fmtflags uppercase = (flags & (ios_base::uppercase));
    fmtflags floatfield = (flags & (ios_base::floatfield));
    fmtflags showpos = (flags & (ios_base::showpos));
    fmtflags showbase = (flags & (ios_base::showbase));
    fmtflags showgrouping = (flags & (ios_base::showgrouping));
    
  2. Change header <ios> synopsis, 27.5.1 [iostreams.base.overview] as indicated:

    #include <iosfwd>
    
    namespace std {
      […]
      // 27.5.6, manipulators:
      […]
      ios_base& showpoint     (ios_base& str);
      ios_base& noshowpoint   (ios_base& str);
      ios_base& showgrouping  (ios_base& str);
      ios_base& noshowgrouping(ios_base& str);
      ios_base& showpos       (ios_base& str);
      ios_base& noshowpos     (ios_base& str);
      […]
    }
    
  3. Change class ios_base synopsis, 27.5.3 [ios.base] as indicated:

    namespace std {
      class ios_base {
      public:
      class failure;
        // 27.5.3.1.2 fmtflags
        typedef T1 fmtflags;
        […]
        static constexpr fmtflags showpoint = unspecified ;
        static constexpr fmtflags showgrouping = unspecified ;
        static constexpr fmtflags showpos = unspecified ;
        […]
      };
    }
    
  4. Add a new entry to Table 122 — "fmtflags effects" as indicated:

    Table 122 — fmtflags effects
    Element Effect(s) if set
    […]
    showpoint generates a decimal-point character unconditionally in generated floatingpoint output
    showgrouping generates grouping characters unconditionally in generated output
    […]
  5. After 27.5.3.1.2 [ios::fmtflags] p12 insert the following:

    ios_base& showgrouping(ios_base& str);
    

    -?- Effects: Calls str.setf(ios_base::showgrouping).

    -?- Returns: str.

    ios_base& noshowgrouping(ios_base& str);
    

    -?- Effects: Calls str.unsetf(ios_base::showgrouping).

    -?- Returns: str.

Proposed resolution:


2121. app for string streams

Section: 27.8.5.1 [stringstream.cons] Status: New Submitter: Nicolai Josuttis Opened: 2012-01-15 Last modified: 2015-04-08

View all issues with New status.

Discussion:

This issue was raised while discussing issue 1448.

Note the following program:

string s("s1: 123456789");
ostringstream s1(s, ios_base::out|ios_base::app);
s1 << "hello";
cout << s1.str() << endl;

With g++4.x it prints:

s1: 123456789hello

With VisualC++10 it prints:

hello23456789

From my intuitive understanding the flag "app" should result in the output of g++4.x. I also would read that from 27.5.3.1.4 [ios::openmode] claiming:

app   seek to end before each write

However in issue 1448 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.

Note that the flag ate on both platforms appends "hello" to s.

Proposed resolution:


2136. Postconditions vs. exceptions

Section: 17.5.1 [structure] Status: Open Submitter: Jens Maurer Opened: 2012-03-08 Last modified: 2015-05-22

View all issues with Open status.

Discussion:

The front matter in clause 17 should clarify that postconditions will not hold if a standard library function exits via an exception. Postconditions or guarantees that apply when an exception is thrown (beyond the basic guarantee) are described in an "Exception safety" section.

[ 2012-10 Portland: Move to Open ]

Consensus that we do not clearly say this, and that we probably should. A likely location to describe the guarantees of postconditions could well be a new sub-clause following 17.6.4.11 [res.on.required] which serves the same purpose for requires clauses. However, we need such wording before we can make progress.

Also, see 2137 for a suggestion that we want to see a paper resolving both issues together.

[2015-05-06 Lenexa: EirkWF to write paper addressing 2136 and 2137]

MC: Idea is to replace all such "If no exception" postconditions with "Exception safety" sections.

Proposed resolution:


2137. Misleadingly constrained post-condition in the presence of exceptions

Section: 28.8.3 [re.regex.assign] Status: Open Submitter: Jonathan Wakely Opened: 2012-03-08 Last modified: 2015-05-22

View all other issues in [re.regex.assign].

View all issues with Open status.

Discussion:

The post-conditions of basic_regex<>::assign 28.8.3 [re.regex.assign] p16 say:

If no exception is thrown, flags() returns f and mark_count() returns the number of marked sub-expressions within the expression.

The default expectation in the library is that post-conditions only hold, if there is no failure (see also 2136), therefore the initial condition should be removed to prevent any misunderstanding.

[ 2012-10 Portland: Move to Open ]

A favorable resolution clearly depends on a favorable resolution to 2136. There is also a concern that this is just one example of where we would want to apply such a wording clean-up, and which is really needed to resolve both this issue and 2136 is a paper providing the clause 17 wording that gives the guarantee for postcondition paragaraphs, and then reviews clauses 18-30 to apply that guarantee consistently. We do not want to pick up these issues piecemeal, as we risk openning many issues in an ongoing process.

[2015-05-06 Lenexa: EirkWF to write paper addressing 2136 and 2137]

Proposed resolution:

This wording is relative to N3376.

template <class string_traits, class A>
  basic_regex& assign(const basic_string<charT, string_traits, A>& s,
    flag_type f = regex_constants::ECMAScript);

[…]

-15- Effects: Assigns the regular expression contained in the string s, interpreted according the flags specified in f. If an exception is thrown, *this is unchanged.

-16- Postconditions: If no exception is thrown, flags() returns f and mark_count() returns the number of marked sub-expressions within the expression.


2139. What is a user-defined type?

Section: 17.6.4.2.1 [namespace.std], 19.5 [syserr], 20.7.7.1 [allocator.uses.trait], 20.9.10.1 [func.bind.isbind], 20.9.10.2 [func.bind.isplace], 20.9.13 [unord.hash], 20.10.7.6 [meta.trans.other], 22.3.1 [locale], 22.4.1.4 [locale.codecvt], 28.12.1.4 [re.regiter.incr] Status: Open Submitter: Loïc Joly Opened: 2012-03-08 Last modified: 2015-05-22

View all other issues in [namespace.std].

View all issues with Open status.

Discussion:

The expression "user-defined type" is used in several places in the standard, but I'm not sure what it means. More specifically, is a type defined in the standard library a user-defined type?

From my understanding of English, it is not. From most of the uses of this term in the standard, it seem to be considered as user defined. In some places, I'm hesitant, e.g. 17.6.4.2.1 [namespace.std] p1:

A program may add a template specialization for any standard library template to namespace std only if the declaration depends on a user-defined type and the specialization meets the standard library requirements for the original template and is not explicitly prohibited.

Does it mean we are allowed to add in the namespace std a specialization for std::vector<std::pair<T, U>>, for instance?

Additional remarks from the reflector discussion: The traditional meaning of user-defined types refers to class types and enum types, but the library actually means here user-defined types that are not (purely) library-provided. Presumably a new term - like user-provided type - should be introduced and properly defined.

[ 2012-10 Portland: Move to Deferred ]

The issue is real, in that we never define this term and rely on a "know it when I see it" intuition. However, there is a fear that any attempt to pin down a definition is more likely to introduce bugs than solve them - getting the wording for this precisely correct is likely far more work than we are able to give it.

There is unease at simple closing as NAD, but not real enthusiasm to provide wording either. Move to Deferred as we are not opposed to some motivated individual coming back with full wording to review, but do not want to go out of our way to encourage someone to work on this in preference to other issues.

[2014-02-20 Re-open Deferred issues as Priority 4]

[2015-03-05 Jonathan suggests wording]

I dislike the suggestion to change to "user-provided" type because I already find the difference between user-declared / user-provided confusing for special member functions, so I think it would be better to use a completely different term. The core language uses "user-defined conversion sequence" and "user-defined literal" and similar terms for things which the library provides, so I think we should not refer to "user" at all to distinguish entities defined outside the implementation from things provided by the implementation.

I propose "program-defined type" (and "program-defined specialization"), defined below. The P/R below demonstrates the scope of the changes required, even if this name isn't adopted. I haven't proposed a change for "User-defined facets" in [locale].

[Lenexa 2015-05-06]

RS, HT: The core language uses "user-defined" in a specific way, including library things but excluding core language things, let's use a different term.

MC: Agree.

RS: "which" should be "that", x2

RS: Is std::vector<MyType> a "program-defined type"?

MC: I think it should be.

TK: std::vector<int> seems to take the same path.

JW: std::vector<MyType> isn't program-defined, we don't need it to be, anything that depends on that also depends on =MyType.

TK: The type defined by an "explicit template specialization" should be a program-defined type.

RS: An implicit instantiation of a "program-defined partial specialization" should also be a program-defined type.

JY: This definition formatting is horrible and ugly, can we do better?

RS: Checking ISO directives.

RS: Define "program-defined type" and "program-defined specialization" instead, to get rid of the angle brackets.

JW redrafting.

Proposed resolution:

This wording is relative to N4296.

  1. Add a new sub-clause to 17.3 [definitions]:

    17.3.? [defns.program.defined]

    program-defined

    <type> a class type or enumeration type which is not part of the C++ standard library and not defined by the implementation. [Note: Types defined by the implementation include extensions (1.4 [intro.compliance]) and internal types used by the library. — end note]

    program-defined

    <specialization> an explicit template specialization or partial specialization which is not part of the C++ standard library and not defined by the implementation.

  2. Change 17.6.4.2.1 [namespace.std] paragraph 1+2:

    -1- The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified. A program may add a template specialization for any standard library template to namespace std only if the declaration depends on a userprogram-defined type and the specialization meets the standard library requirements for the original template and is not explicitly prohibited.

    -2- The behavior of a C++ program is undefined if it declares

    […]

    A program may explicitly instantiate a template defined in the standard library only if the declaration depends on the name of a userprogram-defined type and the instantiation meets the standard library requirements for the original template.

  3. Change 19.5 [syserr] paragraph 4:

    -4- The is_error_code_enum and is_error_condition_enum may be specialized for userprogram-defined types to indicate that such types are eligible for class error_code and class error_condition automatic conversions, respectively.

  4. Change 20.7.7.1 [allocator.uses.trait] paragraph 1:

    -1- Remarks: automatically detects […]. A program may specialize this template to derive from true_type for a userprogram-defined type T that does not have a nested allocator_type but nonetheless can be constructed with an allocator where either: […]

  5. Change 20.9.10.1 [func.bind.isbind] paragraph 2:

    -2- Instantiations of the is_bind_expression template […]. A program may specialize this template for a userprogram-defined type T to have a BaseCharacteristic of true_type to indicate that T should be treated as a subexpression in a bind call.

  6. Change 20.9.10.2 [func.bind.isplace] paragraph 2:

    -2- Instantiations of the is_placeholder template […]. A program may specialize this template for a userprogram-defined type T to have a BaseCharacteristic of integral_constant<int, N> with N > 0 to indicate that T should be treated as a placeholder type.

  7. Change 20.9.13 [unord.hash] paragraph 1:

    The unordered associative containers defined in 23.5 use specializations of the class template hash […], the instantiation hash<Key> shall:

  8. Change 20.10.7.5 [meta.trans.ptr] Table 57 (common_type row):

    Table 57 — Other transformations
    Template Condition Comments
    template <class... T>
    struct common_type;
      The member typedef type shall be
    defined or omitted as specified below.
    […]. A program may
    specialize this trait if at least one
    template parameter in the
    specialization is a userprogram-defined type.
    […]
  9. Change 22.4.1.4 [locale.codecvt] paragraph 3:

    -3- The specializations required in Table 81 (22.3.1.1.1) […]. Other encodings can be converted by specializing on a userprogram-defined stateT type.[…]

  10. Change 28.12.1.4 [re.regiter.incr] paragraph 8:

    -8- [Note: This means that a compiler may call an implementation-specific search function, in which case a userprogram-defined specialization of regex_search will not be called. — end note]


2146. Are reference types Copy/Move-Constructible/Assignable or Destructible?

Section: 17.6.3.1 [utility.arg.requirements] Status: Open Submitter: Nikolay Ivchenkov Opened: 2012-03-23 Last modified: 2015-04-08

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

View all issues with Open status.

Discussion:

According to 17.6.3.1 [utility.arg.requirements] p1

The template definitions in the C++ standard library refer to various named requirements whose details are set out in tables 17-24. In these tables, T is an object or reference type to be supplied by a C++ program instantiating a template; a, b, and c are values of type (possibly const) T; s and t are modifiable lvalues of type T; u denotes an identifier; rv is an rvalue of type T; and v is an lvalue of type (possibly const) T or an rvalue of type const T.

Is it really intended that T may be a reference type? If so, what should a, b, c, s, t, u, rv, and v mean? For example, are "int &" and "int &&" MoveConstructible?

As far as I understand, we can explicitly specify template arguments for std::swap and std::for_each. Can we use reference types there?

  1. #include <iostream>
    #include <utility>
    
    int main()
    {
      int x = 1;
      int y = 2;
      std::swap<int &&>(x, y); // undefined?
      std::cout << x << " " << y << std::endl;
    }
    
  2. #include <algorithm>
    #include <iostream>
    #include <iterator>
    #include <utility>
    
    struct F
    {
      void operator()(int n)
      {
        std::cout << n << std::endl;
        ++count;
      }
      int count;
    } f;
    
    int main()
    {
      int arr[] = { 1, 2, 3 };
      auto&& result = std::for_each<int *, F &&>( // undefined?
        std::begin(arr),
        std::end(arr),
        std::move(f));
      std::cout << "count: " << result.count << std::endl;
    }
    

Are these forms of usage well-defined?

Let's also consider the following constructor of std::thread:

template <class F, class ...Args>
explicit thread(F&& f, Args&&... args);

Requires: F and each Ti in Args shall satisfy the MoveConstructible requirements.

When the first argument of this constructor is an lvalue (e.g. a name of a global function), template argument for F is deduced to be lvalue reference type. What should "MoveConstructible" mean with regard to an lvalue reference type? Maybe the wording should say that std::decay<F>::type and each std::decay<Ti>::type (where Ti is an arbitrary item in Args) shall satisfy the MoveConstructible requirements?

[2013-03-15 Issues Teleconference]

Moved to Open.

The questions raised by the issue are real, and should have a clear answer.

Proposed resolution:


2151. basic_string<>::swap semantics ignore allocators

Section: 21.4.1 [string.require] Status: Open Submitter: Robert Shearer Opened: 2012-04-13 Last modified: 2015-04-08

View all other issues in [string.require].

View all issues with Open status.

Discussion:

In C++11, basic_string is not described as a "container", and is not governed by the allocator-aware container semantics described in sub-clause 23.2 [container.requirements]; as a result, and requirements or contracts for the basic_string interface must be documented in Clause 21 [strings].

Sub-clause 21.4.6.8 [string::swap] defines the swap member function with no requirements, and with guarantees to execute in constant time without throwing. Fulfilling such a contract is not reasonable in the presence of unequal non-propagating allocators.

In contrast, 23.2.1 [container.requirements.general] p7 declares the behavior of member swap for containers with unequal non-propagating allocators to be undefined.

Resolution proposal:

Additional language from Clause 23 [containers] should probably be copied to Clause 21 [strings]. I will refrain from an exactly recommendation, however, as I am raising further issues related to the language in Clause 23 [containers].

[2013-03-15 Issues Teleconference]

Moved to Open.

Alisdair has offered to provide wording.

Telecon notes that 23.2.1 [container.requirements.general]p13 says that string is an allocator-aware container.

Proposed resolution:


2152. Instances of standard container types are not swappable

Section: 17.6.3.2 [swappable.requirements], 23.2.1 [container.requirements.general] Status: Open Submitter: Robert Shearer Opened: 2012-04-13 Last modified: 2015-04-08

View all other issues in [swappable.requirements].

View all issues with Open status.

Discussion:

Sub-clause 17.6.3.2 [swappable.requirements] defines two notions of swappability: a binary version defining when two objects are swappable with one another, and a unary notion defining whether an object is swappable (without qualification), with the latter definition requiring that the object satisfy the former with respect to all values of the same type.

Let T be a container type based on a non-propagating allocator whose instances do not necessarily compare equal. Then sub-clause 23.2.1 [container.requirements.general] p7 implies that no object t of type T is swappable (by the unary definition).

Throughout the standard it is the unary definition of "swappable" that is listed as a requirement (with the exceptions of 20.2.2 [utility.swap] p4, 20.3.2 [pairs.pair] p31, 20.4.2.3 [tuple.swap] p2, 25.3.3 [alg.swap] p2, and 25.3.3 [alg.swap] p6, which use the binary definition). This renders many of the mutating sequence algorithms of sub-clause 25.3 [alg.modifying.operations], for example, inapplicable to sequences of standard container types, even where every element of the sequence is swappable with every other.

Note that this concern extends beyond standard containers to all future allocator-based types.

Resolution proposal:

I see two distinct straightforward solutions:

  1. Modify the requirements of algorithms from sub-clause 25.3 [alg.modifying.operations], and all other places that reference the unary "swappable" definition, to instead use the binary "swappable with" definition (over a domain appropriate to the context). The unary definition of "swappable" could then be removed from the standard.
  2. Modify sub-clause 23.2.1 [container.requirements.general] such that objects of standard container types are "swappable" by the unary definition.

I favor the latter solution, for reasons detailed in the following issue.

[ 2012-10 Portland: Move to Open ]

The issue is broader than containers with stateful allocotors, although they are the most obvious example contained within the standard itself. The basic problem is that once you have a stateful allocator, that does not propagate_on_swap, then whether two objects of this type can be swapped with well defined behavior is a run-time property (the allocators compare equal) rather than a simple compile-time property that can be deduced from the type. Strictly speaking, any type where the nature of swap is a runtime property does not meet the swappable requirements of C++11, although typical sequences of such types are going to have elements that are all swappable with any other element in the sequence (using our other term of art for specifying requirements) as the common case is a container of elements who all share the same allocator.

The heart of the problem is that the swappable requirments demand that any two objects of the same type be swappable with each other, so if any two such objects would not be swappable with each other, then the whole type is never swappable. Many algorithms in clause 25 are specified in terms of swappable which is essentially an overspecification as all they actually need is that any element in the sequence is swappable with any other element in the sequence.

At this point Howard joins the discussion and points out that the intent of introducing the two swap-related terms was to support vector<bool>::reference types, and we are reading something into the wording that was never intended. Consuses is that regardless of the intent, that is what the words today say.

There is some support to see a paper reviewing the whole of clause 25 for this issue, and other select clauses as may be necessary.

There was some consideration to introducing a note into the front of clause 25 to indicate swappable requirements in the clause should be interpreted to allow such awkward types, but ultimately no real enthusiasm for introducing a swappable for clause 25 requirement term, especially if it confusingly had the same name as a term used with a subtly different meaning through the rest of the standard.

There was no enthusiasm for the alternate resolution of requiring containers with unequal allocators that do not propagate provide a well-defined swap behavior, as it is not believed to be possible without giving swap linear complexity for such values, and even then would require adding the constraint that the container element types are CopyConstructible.

Final conclusion: move to open pending a paper from a party with a strong interest in stateful allocators.

Proposed resolution:


2153. Narrowing of the non-member swap contract

Section: 20.2.2 [utility.swap], 17.6.3.2 [swappable.requirements], 23.2.1 [container.requirements.general] Status: Open Submitter: Robert Shearer Opened: 2012-04-13 Last modified: 2015-04-08

View all issues with Open status.

Discussion:

Sub-clause 20.2.2 [utility.swap] defines a non-member 'swap' function with defined behavior for all MoveConstructible and MoveAssignable types. It does not guarantee constant-time complexity or noexcept in general, however this definition does render all objects of MoveConstructible and MoveAssignable type swappable (by the unary definition of sub-clause 17.6.3.2 [swappable.requirements]) in the absence of specializations or overloads.

The overload of the non-member swap function defined in Table 96, however, defines semantics incompatible with the generic non-member swap function, since it is defined to call a member swap function whose semantics are undefined for some values of MoveConstructible and MoveAssignable types.

The obvious (perhaps naive) interpretation of sub-clause 17.6.3.2 [swappable.requirements] is as a guide to the "right" semantics to provide for a non-member swap function (called in the context defined by 17.6.3.2 [swappable.requirements] p3) in order to provide interoperable user-defined types for generic programming. The standard container types don't follow these guidelines.

More generally, the design in the standard represents a classic example of "contract narrowing". It is entirely reasonable for the contract of a particular swap overload to provide more guarantees, such as constant-time execution and noexcept, than are provided by the swap that is provided for any MoveConstructible and MoveAssignable types, but it is not reasonable for such an overload to fail to live up to the guarantees it provides for general types when it is applied to more specific types. Such an overload or specialization in generic programming is akin to an override of an inherited virtual function in OO programming: violating a superclass contract in a subclass may be legal from the point of view of the language, but it is poor design and can easily lead to errors. While we cannot prevent user code from providing overloads that violate the more general swap contract, we can avoid doing so within the library itself.

My proposed resolution is to draw a sharp distinction between member swap functions, which provide optimal performance but idiosyncratic contracts, and non-member swap functions, which should always fulfill at least the contract of 20.2.2 [utility.swap] and thus render objects swappable. The member swap for containers with non-propagating allocators, for example, would offer constant-time guarantees and noexcept but would only offer defined behavior for values with allocators that compare equal; non-member swap would test allocator equality and then dispatch to either member swap or std::swap depending on the result, providing defined behavior for all values (and rendering the type "swappable"), but offering neither the constant-time nor the noexcept guarantees.

[2013-03-15 Issues Teleconference]

Moved to Open.

This topic deserves more attention than can be given in the telocon, and there is no proposed resolution.

Proposed resolution:


2154. What exactly does compile-time complexity imply?

Section: 26.5.1.3 [rand.req.urng] Status: New Submitter: John Salmon Opened: 2012-04-26 Last modified: 2015-04-08

View all other issues in [rand.req.urng].

View all issues with New status.

Discussion:

The expressions G::min() and G::max() in Table 116 in 26.5.1.3 [rand.req.urng] are specified as having "compile-time" complexity.

It is not clear what, exactly, this requirement implies. If a URNG has a method:

static int min();

then is the method required to have a constexpr qualifier? I believe the standard would benefit from clarification of this point.

Proposed resolution:


2155. Macro __bool_true_false_are_defined should be removed

Section: 18.10 [support.runtime] Status: Open Submitter: Thomas Plum Opened: 2012-04-30 Last modified: 2015-05-08

View other active issues in [support.runtime].

View all other issues in [support.runtime].

View all issues with Open status.

Discussion:

Since C99, the C standard describes a macro named __bool_true_false_are_defined.

In the process of harmonizing C++11 with C99, this name became part of the C++ standard.

I propose that all mention of this name should be removed from the C and C++ standards.

Here's the problem: The name was originally proposed as a transition tool, so that the headers for a project could contain lines like the following.

#if !defined(__bool_true_false_are_defined)
#define bool int /* or whatever */
#define true 1
#define false 0
#endif

Then when the project was compiled by a "new" compiler that implemented bool as defined by the evolving C++98 or C99 standards, those lines would be skipped; but when compiled by an "old" compiler that didn't yet provide bool, true, and false, then the #define's would provide a simulation that worked for most purposes.

It turns out that there is an unfortunate ambiguity in the name. One interpretation is as shown above, but a different reading says "bool, true, and false are #define'd", i.e. that the meaning of the macro is to assert that these names are macros (not built-in) ... which is true in C, but not in C++.

In C++11, the name appears in parentheses followed by a stray period, so some editorial change is needed in any event:

18.10 [support.runtime] para 1:

Headers <csetjmp> (nonlocal jumps), <csignal> (signal handling), <cstdalign> (alignment), <cstdarg> (variable arguments), <cstdbool> (__bool_true_false_are_defined). <cstdlib> (runtime environment getenv(), system()), and <ctime> (system clock clock(), time()) provide further compatibility with C code.

However, para 2 says

"The contents of these headers are the same as the Standard C library headers <setjmp.h>, <signal.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>, <stdlib.h>, and <time.h>, respectively, with the following changes:",

and para 8 says

"The header <cstdbool> and the header <stdbool.h> shall not define macros named bool, true, or false."

Thus para 8 doesn't exempt the C++ implementation from the arguably clear requirement of the C standard, to provide a macro named __bool_true_false_are_defined defined to be 1.

Real implementations of the C++ library differ, so the user cannot count upon any consistency; furthermore, the usefulness of the transition tool has faded long ago.

That's why my suggestion is that both C and C++ standards should eliminate any mention of __bool_true_false_are_defined. In that case, the name belongs to implementers to provide, or not, as they choose.

[2013-03-15 Issues Teleconference]

Moved to Open.

While not strictly necessary, the clean-up look good.

We would like to hear from our C liaison before moving on this issue though.

[2015-05 Lenexa]

LWG agrees. Jonathan provides wording.

Proposed resolution:

This wording is relative to N4296.

  1. Edit the footnote on 17.6.1.2 [headers] p7:

    176) In particular, including any of the standard headers <stdbool.h>, <cstdbool>, <iso646.h> or <ciso646> has no effect.

  2. Edit 18.10 [support.runtime] p1 as indicated (and remove the index entry for __bool_true_false_are_defined):

    -1- Headers <csetjmp> (nonlocal jumps), <csignal> (signal handling), <cstdalign> (alignment), <cstdarg> (variable arguments), <cstdbool>, (__bool_true_false_are_defined). <cstdlib> (runtime environment getenv(), system()), and <ctime> (system clock clock(), time()) provide further compatibility with C code.

  3. Remove Table 38 — Header <cstdbool> synopsis [tab:support.hdr.cstdbool] from 18.10 [support.runtime]

    Table 38 — Header <cstdbool> synopsis
    TypeName(s)
    Macro:__bool_true_false_are_defined

2157. How does std::array<T,0> initialization work when T is not default-constructible?

Section: 23.3.2.8 [array.zero] Status: Open Submitter: Daryle Walker Opened: 2012-05-08 Last modified: 2015-04-08

View all other issues in [array.zero].

View all issues with Open status.

Discussion:

Objects of std::array<T,N> are supposed to be initialized with aggregate initialization (when not the destination of a copy or move). This clearly works when N is positive. What happens when N is zero? To continue using an (inner) set of braces for initialization, a std::array<T,0> implementation must have an array member of at least one element, and let default initialization take care of those secret elements. This cannot work when T has a set of constructors and the default constructor is deleted from that set. Solution: Add a new paragraph in 23.3.2.8 [array.zero]:

The unspecified internal structure of array for this case shall allow initializations like:

array<T, 0> a = { };

and said initializations must be valid even when T is not default-constructible.

[2012, Portland: Move to Open]

Some discussion to understand the issue, which is that implementations currently have freedom to implement an empty array by holding a dummy element, and so might not support value initialization, which is surprising when trying to construct an empty container. However, this is not mandated, it is an unspecified implementation detail.

Jeffrey points out that the implication of 23.3.2.1 [array.overview] is that this initialization syntax must be supported by empty array objects already. This is a surprising inference that was not obvious to the room, but consensus is that the reading is accurate, so the proposed resolution is not necessary, although the increased clarity may be useful.

Further observation is that the same clause effectively implies that T must always be DefaultConstructible, regardless of N for the same reasons - as an initializer-list may not supply enough values, and the remaining elements must all be value initialized.

Concern that we are dancing angels on the head of pin, and that relying on such subtle implications in wording is not helpful. We need a clarification of the text in this area, and await wording.

[2015-02 Cologne]

DK: What was the outcome of Portland? AM: Initially we thought we already had the intended behaviour. We concluded that T must always be DefaultConstructible, but I'm not sure why. GR: It's p2 in std::array, "up to N". AM: That wording already implies that "{}" has to work when N is zero. But the wording of p2 needs to be fixed to make clear that it does not imply that T must be DefaultConstructible.

Conclusion: Update wording, revisit later.

Proposed resolution:

This wording is relative to N3376.

Add the following new paragraph between the current 23.3.2.8 [array.zero] p1 and p2:

-1- array shall provide support for the special case N == 0.

-?- The unspecified internal structure of array for this case shall allow initializations like:

array<T, 0> a = { };

and said initializations must be valid even when T is not default-constructible.

-2- In the case that N == 0, begin() == end() == unique value. The return value of data() is unspecified.

-3- The effect of calling front() or back() for a zero-sized array is undefined.

-4- Member function swap() shall have a noexcept-specification which is equivalent to noexcept(true).


2158. Conditional copy/move in std::vector

Section: 23.3.6.3 [vector.capacity] Status: New Submitter: Nikolay Ivchenkov Opened: 2012-05-08 Last modified: 2015-04-08

View other active issues in [vector.capacity].

View all other issues in [vector.capacity].

View all issues with New status.

Discussion:

There are various operations on std::vector that can cause elements of the vector to be moved from one location to another. A move operation can use either rvalue or const lvalue as argument; the choice depends on the value of !is_nothrow_move_constructible<T>::value && is_copy_constructible<T>::value, where T is the element type. Thus, some operations on std::vector (e.g. 'resize' with single parameter, 'reserve', 'emplace_back') should have conditional requirements. For example, let's consider the requirement for 'reserve' in N3376 – 23.3.6.3 [vector.capacity]/2:

Requires: T shall be MoveInsertable into *this.

This requirement is not sufficient if an implementation is free to select copy constructor when !is_nothrow_move_constructible<T>::value && is_copy_constructible<T>::value evaluates to true. Unfortunately, is_copy_constructible cannot reliably determine whether T is really copy-constructible. A class may contain public non-deleted copy constructor whose definition does not exist or cannot be instantiated successfully (e.g., std::vector<std::unique_ptr<int>> has copy constructor, but this type is not copy-constructible). Thus, the actual requirements should be:

Maybe it would be useful to introduce a new name for such conditional requirement (in addition to "CopyInsertable" and "MoveInsertable").

Proposed resolution:


2161. const equivalence of std::map

Section: 23.4 [associative], 23.5 [unord] Status: New Submitter: Bjarne Stroustrup Opened: 2012-06-18 Last modified: 2015-04-08

View other active issues in [associative].

View all other issues in [associative].

View all issues with New status.

Discussion:

As described in the reflector discussion c++std-core-21860 consider the following example:

map<const int, int> mci{};
map<int, int> mi = mci; // ??
mci[1] = 2;
mi[1] = 2;

Should it be required that the marked initialization is well-formed? As a possible solution this could be realized by an alias template:

template <class K, class T>
struct OriginalMap { […] };

template <class K, class T>
using ImprovedMap = OriginalMap<const K, T>;

Proposed resolution:


2164. What are the semantics of vector.emplace(vector.begin(), vector.back())?

Section: 23.3.6.5 [vector.modifiers], 23.2 [container.requirements] Status: New Submitter: Howard Hinnant Opened: 2012-07-07 Last modified: 2015-04-08

View other active issues in [vector.modifiers].

View all other issues in [vector.modifiers].

View all issues with New status.

Discussion:

Nikolay Ivchenkov recently brought the following example on the std-discussion newsgroup, asking whether the following program well-defined:

#include <iostream>
#include <vector>

int main()
{
  std::vector<int> v;
  v.reserve(4);
  v = { 1, 2, 3 };
  v.emplace(v.begin(), v.back());
  for (int x : v)
    std::cout << x << std::endl;
}

Nikolay Ivchenkov:

I think that an implementation of vector's 'emplace' should initialize an intermediate object with v.back() before any shifts take place, then perform all necessary shifts and finally replace the value pointed to by v.begin() with the value of the intermediate object. So, I would expect the following output:

3
1
2
3

GNU C++ 4.7.1 and GNU C++ 4.8.0 produce other results:

2
1
2
3

Howard Hinnant:

I believe Nikolay is correct that vector should initialize an intermediate object with v.back() before any shifts take place. As Nikolay pointed out in another email, this appears to be the only way to satisfy the strong exception guarantee when an exception is not thrown by T's copy constructor, move constructor, copy assignment operator, or move assignment operator as specified by 23.3.6.5 [vector.modifiers]/p1. I.e. if the emplace construction throws, the vector must remain unaltered.

That leads to an implementation that tolerates objects bound to the function parameter pack of the emplace member function may be elements or sub-objects of elements of the container.

My position is that the standard is correct as written, but needs a clarification in this area. Self-referencing emplace should be legal and give the result Nikolay expects. The proposed resolution of LWG 760 is not correct.

[2015-02 Cologne]

LWG agrees with the analysis including the assessment of LWG 760 and would appreciate a concrete wording proposal.

[2015-04-07 dyp comments]

The Standard currently does not require that creation of such intermediate objects is legal. 23.2.3 [sequence.reqmts] Table 100 — "Sequence container requirements" currently specifies:

Table 100 — Sequence container requirements
Expression Return type Assertion/note
pre-/post-condition
a.emplace(p, args); iterator Requires: T is EmplaceConstructible into X from args. For vector and deque, T is also MoveInsertable into X and MoveAssignable. […]

The EmplaceConstructible concept is defined via allocator_traits<A>::construct in 23.2.1 [container.requirements.general] p15.5 That's surprising to me since the related concepts use the suffix Insertable if they refer to the allocator. An additional requirement such as std::is_constructible<T, Args...> is necessary to allow creation of intermediate objects.

The creation of intermediate objects also affects other functions, such as vector.insert. Since aliasing the vector is only allowed for the single-element forms of insert and emplace (see 526), the range-forms are not affected. Similarly, aliasing is not allowed for the rvalue-reference overload. See also LWG 2266.

There might be a problem with a requirement of std::is_constructible<T, Args...> related to the issues described in LWG 2461. For example, a scoped allocator adapter passes additional arguments to the constructor of the value type. This is currently not done in recent implementations of libstdc++ and libc++ when creating the intermediate objects, they simply create the intermediate object by perfectly forwarding the arguments. If such an intermediate object is then moved to its final destination in the vector, a change of the allocator instance might be required — potentially leading to an expensive copy. One can also imagine worse problems, such as run-time errors (allocators not comparing equal at run-time) or compile-time errors (if the value type cannot be created without the additional arguments). I have not looked in detail into this issue, but I'd be reluctant adding a requirement such as std::is_constructible<T, Args...> without further investigation.

It should be noted that the creation of intermediate objects currently is inconsistent in libstdc++ vs libc++. For example, libstdc++ creates an intermediate object for vector.insert, but not vector.emplace, whereas libc++ does the exact opposite in this respect.

A live demo of the inconsistent creation of intermediate objects can be found here.

Proposed resolution:


2165. std::atomic<X> requires X to be nothrow default constructible

Section: 29.5 [atomics.types.generic], 29.6 [atomics.types.operations] Status: Core Submitter: Jonathan Wakely Opened: 2012-07-19 Last modified: 2015-04-09

View other active issues in [atomics.types.generic].

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

View all issues with Core status.

Discussion:

As raised in c++std-lib-32781, this fails to compile even though the default constructor is not used:

#include <atomic>

struct X {
  X() noexcept(false) {}
  X(int) { }
};

std::atomic<X> x(3);

This is because atomic<T>'s default constructor is declared to be non-throwing and is explicitly-defaulted on its first declaration:

atomic() noexcept = default;

This is ill-formed if the implicitly-declared default constructor would not be non-throwing.

Possible solutions:

  1. Add nothrow default constructible to requirements for template argument of the generic atomic<T>
  2. Remove atomic<T>::atomic() from the overload set if T is not nothrow default constructible.
  3. Remove noexcept from atomic<T>::atomic(), allowing it to be deduced (but the default constructor is intended to be always noexcept)
  4. Do not default atomic<T>::atomic() on its first declaration (but makes the default constructor user-provided and so prevents atomic<T> being trivial)
  5. A core change to allow the mismatched exception specification if the default constructor isn't used (see c++std-core-21990)

[2012, Portland: move to Core]

Recommend referring to core to see if the constructor noexcept mismatch can be resolved there. The issue is not specific to concurrency.

[2015-04-09 Daniel comments]

CWG issue 1778, which had been created in behalf of this LWG issue, has been resolved as a defect.

Proposed resolution:


2166. Heap property underspecified?

Section: 25.4.6 [alg.heap.operations] Status: New Submitter: Peter Sommerlad Opened: 2012-07-09 Last modified: 2015-04-08

View all other issues in [alg.heap.operations].

View all issues with New status.

Discussion:

Another similar issue to the operator< vs greater in nth_element but not as direct occurs in 25.4.6 [alg.heap.operations]:

-1- A heap is a particular organization of elements in a range between two random access iterators [a,b). Its two key properties are:

  1. There is no element greater than *a in the range and
  2. *a may be removed by pop_heap(), or a new element added by push_heap(), in O(log(N)) time.

As noted by Richard Smith, it seems that the first bullet should read:

*a is not less than any element in the range

Even better the heap condition could be stated here directly, instead of leaving it unspecified, i.e.,

Each element at (a+2*i+1) and (a+2*i+2) is less than the element at (a+i), if those elements exist, for i>=0.

But may be that was may be intentional to allow other heap organizations?

See also follow-up discussion of c++std-lib-32780.

Proposed resolution:


2173. The meaning of operator + in the description of the algorithms

Section: 25 [algorithms] Status: New Submitter: Nikolay Ivchenkov Opened: 2012-08-01 Last modified: 2015-04-08

View other active issues in [algorithms].

View all other issues in [algorithms].

View all issues with New status.

Discussion:

According to 25.1 [algorithms.general]/12,

In the description of the algorithms operators + and - are used for some of the iterator categories for which they do not have to be defined. In these cases the semantics of a+n is the same as that of

X tmp = a;
advance(tmp, n);
return tmp;

There are several places where such operator + is applied to an output iterator — for example, see the description of std::copy:

template<class InputIterator, class OutputIterator>
OutputIterator copy(InputIterator first, InputIterator last,
                    OutputIterator result);

-1- Effects: Copies elements in the range [first,last) into the range [result,result + (last - first)) starting from first and proceeding to last. For each non-negative integer n < (last - first), performs *(result + n) = *(first + n).

std::advance is not supposed to be applicable to output iterators, so we need a different method of description.

See also message c++std-lib-32908.

[2014-06-07 Daniel comments and provides wording]

The specification for output iterators is somewhat tricky, because here a sequence of increments is required to be combined with intervening assignments to the dereferenced iterator. I tried to respect this fact by using a conceptual assignment operation as part of the specification.

Another problem in the provided as-if-code is the question which requirements are imposed on n. Unfortunately, the corresponding function advance is completely underspecified in this regard, so I couldn't borrow wording from it. We cannot even assume here that n is the difference type of the iterator, because for output iterators there is no requirements for this associated type to be defined. The presented wording attempts to minimize assumptions, but still can be considered as controversial.

Proposed resolution:

This wording is relative to N3936.

  1. Change 25.1 [algorithms.general] around p12 as indicated:

    -12- In the description of the algorithms operators + and - are used for some of the iterator categories for which they do not have to be defined. In these cases the semantics of a+n is the same as that of

    X tmp = a;
    advance(tmp, n);
    return tmp;
    

    when X meets the input iterator requirements (24.2.3 [input.iterators]), otherwise it is the same as that of

    X tmp = a;
    for (auto i = n; i; ++tmp, (void) --i) 
      *tmp = Expr(i); 
    return tmp;
    

    where Expr(i) denotes the n-i-th expression that is assigned to for the corresponding algorithm; and that of b-a is the same as of

    return distance(a, b);
    

2178. Allocator requirement changes not mentioned Annex C

Section: 17.6.3.5 [allocator.requirements], C.5 [diff.library] Status: Open Submitter: Nevin Liber Opened: 2012-08-14 Last modified: 2015-04-08

View other active issues in [allocator.requirements].

View all other issues in [allocator.requirements].

View all issues with Open status.

Discussion:

Given that a number of things were removed from the allocator requirements (reference, const_reference, address() in 17.6.3.5 [allocator.requirements]), it seems that these incompatible changes should be mentioned in Annex C.5 [diff.library], more specifically in [diff.cpp03].

[ 2012-10 Portland: Move to Open ]

It was clearly pointed out by Bill during the C++11 process that our change to allocator requirements potentially broke 3rd party user containers written to expect C++03 allocators, or rather, an allocator written to the minimal requirements of C++11 might not be guaranteed to work with a container written to the previous rules. This was a trade-off in making allocaters easier to write by use of the allocator_traits framework.

This probably does merit a write-up in Annex C, and we look forward to seeing wording. Until then, the best we can do is move the issue to Open.

Proposed resolution:


2179. enable_shared_from_this and construction from raw pointers

Section: 20.8.2.5 [util.smartptr.enab], 20.8.2.2.1 [util.smartptr.shared.const] Status: Open Submitter: Daniel Krügler Opened: 2012-08-16 Last modified: 2015-04-08

View all issues with Open status.

Discussion:

On reflector message c++std-lib-32927, Matt Austern asked whether the following example should be well-defined or not

struct X : public enable_shared_from_this<X> { };
auto xraw = new X;
shared_ptr<X> xp1(xraw);
shared_ptr<X> xp2(xraw);

pointing out that 20.8.2.2.1 [util.smartptr.shared.const] does not seem to allow it, since xp1 and xp2 aren't allowed to share ownership, because each of them is required to have use_count() == 1. Despite this wording it might be reasonable (and technical possible) to implement that request.

On the other hand, there is the non-normative note in 20.8.2.5 [util.smartptr.enab] p11 (already part of TR1):

The shared_ptr constructors that create unique pointers can detect the presence of an enable_shared_from_this base and assign the newly created shared_ptr to its __weak_this member.

Now according to the specification in 20.8.2.2.1 [util.smartptr.shared.const] p3-7:

template<class Y> explicit shared_ptr(Y* p);

the notion of creating unique pointers can be read to be included by this note, because the post-condition of this constructor is unique() == true. Evidence for this interpretation seems to be weak, though.

Howard Hinnant presented the counter argument, that actually the following is an "anti-idiom" and it seems questionable to teach it to be well-defined in any case:

auto xraw = new X;
shared_ptr<X> xp1(xraw);
shared_ptr<X> xp2(xraw);

He also pointed out that the current post-conditions of the affected shared_ptr constructor would need to be reworded.

It needs to be decided, which direction to follow. If this idiom seems too much broken to be supported, the note could be improved. If it should be supported, the constructors in 20.8.2.2.1 [util.smartptr.shared.const] need a careful analysis to ensure that post-conditions are correct.

Several library implementations currently do not support this example, instead they typically cause a crash. Matt points out that there are currently no explicit requirements imposed on shared_ptr objects to prevent them from owning the same underlying object without sharing the ownership. It might be useful to add such a requirement.

[2013-03-15 Issues Teleconference]

Moved to Open.

More discussion is needed to pick a direction to guide a proposed resolution.

[2013-05-09 Jonathan comments]

The note says the newly created shared_ptr is assigned to the weak_ptr member. It doesn't say before doing that the shared_ptr should check if the weak_ptr is non-empty and possibly share ownership with some other pre-existing shared_ptr.

Proposed resolution:


2183. Muddled allocator requirements for match_results constructors

Section: 28.10.1 [re.results.const], 28.10.6 [re.results.all] Status: New Submitter: Pete Becker Opened: 2012-08-29 Last modified: 2015-04-08

View other active issues in [re.results.const].

View all other issues in [re.results.const].

View all issues with New status.

Discussion:

28.10.1 [re.results.const] p1 says:

In all match_results constructors, a copy of the Allocator argument shall be used for any memory allocation performed by the constructor or member functions during the lifetime of the object.

There are three constructors:

match_results(const Allocator& = Allocator());
match_results(const match_results& m);
match_results(match_results&& m) noexcept;

The second and third constructors do no have an Allocator argument, so despite the "all match_results constructors", it is not possible to use "the Allocator argument" for the second and third constructors.

The requirements for those two constructors also does not give any guidance. The second constructor has no language about allocators, and the third states that the stored Allocator value is move constructed from m.get_allocator(), but doesn't require using that allocator to allocate memory.

The same basic problem recurs in 28.10.6 [re.results.all], which gives the required return value for get_allocator():

Returns: A copy of the Allocator that was passed to the object's constructor or, if that allocator has been replaced, a copy of the most recent replacement.

Again, the second and third constructors do not take an Allocator, so there is nothing that meets this requirement when those constructors are used.

Proposed resolution:


2184. Muddled allocator requirements for match_results assignments

Section: 28.10.1 [re.results.const], 28.10.6 [re.results.all] Status: New Submitter: Pete Becker Opened: 2012-08-29 Last modified: 2015-04-08

View other active issues in [re.results.const].

View all other issues in [re.results.const].

View all issues with New status.

Discussion:

The effects of the two assignment operators are specified in Table 141. Table 141 makes no mention of allocators, so, presumably, they don't touch the target object's allocator. That's okay, but it leaves the question: match_results::get_allocator() is supposed to return "A copy of the Allocator that was passed to the object's constructor or, if that allocator has been replaced, a copy of the most recent replacement"; if assignment doesn't replace the allocator, how can the allocator be replaced?

Proposed resolution:


2189. Throwing swap breaks unordered containers' state

Section: 23.2.5.1 [unord.req.except] Status: Open Submitter: Alisdair Meredith Opened: 2012-09-23 Last modified: 2015-04-08

View all issues with Open status.

Discussion:

The hash functor and key-comparison functor of unordered containers are allowed to throw on swap.

23.2.5.1 [unord.req.except]p3 "For unordered associative containers, no swap function throws an exception unless that exception is thrown by the swap of the container's Hash or Pred object (if any)."

In such a case we must offer the basic exception safety guarantee, where both objects are left in valid but unspecified states, and no resources are leaked. This yields a corrupt, un-usable container if the first swap succeeds, but the second fails by throwing, as the functors form a matched pair.

So our basic scenario is first, swap the allocators if the allocators propagate on swap, according to allocator_traits. Next we swap the pointers to our internal hash table data structures, so that they match the allocators that allocated them. (Typically, this operation cannot throw). Now our containers are back in a safely destructible state if an exception follows.

Next, let's say we swap the hash functor, and that throws. We have a corrupt data structure, in that the buckets are not correctly indexed by the correct functors, lookups will give unpredicatable results etc. We can safely restore a usable state by forcibly clearing each container - which does not leak resources and leaves us with two (empty but) usable containers.

Now let us assume that the hasher swap succeeds. Next we swap the equality comparator functor, and this too could throw. The important point to bear in mind is that these two functors form an important pairing - two objects that compare equal by the equality functor must also hash to the same value. If we swap one without the other, we most likely leave the container in an unusable state, even if we clear out all elements.

1. A colleague pointed out that the solution for this is to dynamically allocate the two functors, and then we need only swap pointers, which is not a throwing operation. And if we don't want to allocate on default construction (a common QoI request), we might consider moving to a dynamically allocated functors whenever swap is called, or on first insertion. Of course, allocating memory in swap is a whole new can of worms, but this does not really sound like the design we had intended.

2. The simplest option is to say that we do not support hasher or equality functors that throw on ADL swap. Note that the requirement is simply to not throw, rather than to be explicitly marked as noexcept. Throwing functors are allowed, so long as we never use values that would actually manifest a throw when used in an unordered container.

Pablo went on to give me several more options, to be sure we have a full set to consider:

3. Disallow one or the other functor from throwing. In that case, the possibly-throwing functor must be swapped first, then the other functor, the allocator, and the data pointer(s) afterwards (in any order -- there was a TC that allocator assignment and swap may not throw if the corresponding propagation trait is true.). Of course, the question becomes: which functor is allowed to throw and which one is not?

4. Require that any successful functor swap be reliably reversible. This is very inventive. I know of no other place in the standard where such a requirement is stated, though I have occasionally wanted such a guarantee.

5. Allow a failed swap to leave the containers in a state where future insertions may fail for reasons other than is currently allowed. Specifically, if the hash and equality functors are out of sync, all insertions will fail. Presumably some "incompletely swapped" exception would be thrown. This is "slightly" inventive, although people have been discussing "radioactive" states for a while.

[2013-03-15 Issues Teleconference]

Moved to Open.

Proposed resolution:


2191. Incorrect specification of match_results(match_results&&)

Section: 28.10.1 [re.results.const] Status: New Submitter: Pete Becker Opened: 2012-10-02 Last modified: 2015-04-08

View other active issues in [re.results.const].

View all other issues in [re.results.const].

View all issues with New status.

Discussion:

28.10.1 [re.results.const]/3: "Move-constructs an object of class match_results satisfying the same postconditions as Table 141."

Table 141 lists various member functions and says that their results should be the results of the corresponding member function calls on m. But m has been moved from, so the actual requirement ought to be based on the value that m had before the move construction, not on m itself.

In addition to that, the requirements for the copy constructor should refer to Table 141.

Ganesh:

Also, the requirements for move-assignment should refer to Table 141. Further it seems as if in Table 141 all phrases of "for all integers n < m.size()" should be replaced by "for all unsigned integers n < m.size()".

Proposed resolution:


2192. Validity and return type of std::abs(0u) is unclear

Section: 26.8 [c.math] Status: Open Submitter: Daniel Krügler Opened: 2012-10-02 Last modified: 2015-05-22

View other active issues in [c.math].

View all other issues in [c.math].

View all issues with Open status.

Discussion:

In C++03 the following two programs are invalid:

  1. #include <cmath>
    
    int main() {
      std::abs(0u);
    }
    
  2. #include <cstdlib>
    
    int main() {
      std::abs(0u);
    }
    

because none of the std::abs() overloads is a best match.

In C++11 the additional "sufficient overload" rule from 26.8 [c.math] p11 (see also LWG 2086) can be read to be applicable to the std::abs() overloads as well, which can lead to the following possible conclusions:

  1. The program

    #include <type_traits>
    #include <cmath>
    
    static_assert(std::is_same<decltype(std::abs(0u)), double>(), "Oops");
    
    int main() {
      std::abs(0u); // Calls std::abs(double)
    }
    

    is required to be well-formed, because of sub-bullet 2 ("[..] or an integer type [..]") of 26.8 [c.math] p11 (Note that the current resolution of LWG 2086 doesn't fix this problem).

  2. Any translation unit including both <cmath> and <cstdlib> might be ill-formed because of two conflicting requirements for the return type of the overload std::abs(int).

It seems to me that at least the second outcome is not intended, personally I think that both are unfortunate: In contrast to all other floating-point functions explicitly listed in sub-clause 26.8 [c.math], the abs overloads have a special and well-defined meaning for signed integers and thus have explicit overloads returning a signed integral type. I also believe that there is no problem accepting that std::fabs(0u) is well-defined with return type double, because the leading 'f' clearly signals that we have a floating point function here. But the expected return type of std::abs(0u) seems less than clear to me. A very reasonable answer could be that this has the same type as its argument type, alternatively it could be a reasonably chosen signed integer type, or a floating point type. It should also be noted, that the corresponding "generic type function" rule set from C99/C1x in 7.25 p2+3 is restricted to the floating-point functions from <math.h> and <complex.h>, so cannot be applied to the abs functions (but to the fabs functions!).

Selecting a signed integer return type for unsigned input values can also problematic: The directly corresponding signed integer type would give half of the possible argument values an implementation-defined result value. Choosing the first signed integer value that can represent all positive values would solve this problem for unsigned int, but there would be no clear answer for the input type std::uintmax_t.

Based on this it seems to me that the C++03 state in regard to unsigned integer values was the better situation, alerting the user that this code is ambigious at the moment (This might be change with different core-language rules as described in N3387).

[2013-04-20, Bristol]

Resolution: leave as new and bring it back in Chicago.

[2013-09 Chicago]

This issue also relates to LWG 2294

STL: these two issues should be bundled

Stefanus: do what Pete says, and add overloads for unsigned to return directly

STL: agree Consensus that this is an issue

Walter: motion to move to Open

STL: no wording for 2294

Stefanus: move to open and note the 2 issues are related and should be moved together

Stefanus: add and define unsigned versions of abs()

[2014-02-03 Howard comments]

Defining abs() for unsigned integers is a bad idea. Doing so would turn compile time errors into run time errors, especially in C++ where we have templates, and the types involved are not always apparent to the programmer at design time. For example, consider:

template <class Int>
Int
analyze(Int x, Int y)
{
  // ...
  if (std::abs(x - y) < threshold)
  {
    // ...
  }
  // ...
}

std::abs(expr) is often used to ask: Are these two numbers sufficiently close? When the assumption is that the two numbers are signed (either signed integral, or floating point), the logic is sound. But when the same logic is accidentally used with an arithmetic type not capable of representing negative numbers, and especially if unsigned overflow will silently happen, then the logic is no longer correct:

auto i = analyze(20u, 21u);  // Today a compile time error
    // But with abs(unsigned) becomes a run time error

This is not idle speculation. Search the net for "abs unsigned" here or here.

In C++11, chrono durations and time_points are allowed to be based on unsigned integers. Taking the absolute value of the difference of two such time_points would be easy to accidentally do (say in code templated on time_points), and would certainly be a logic bug, caught at compile time unless we provide the error prone abs(unsigned).

[2015-02, Cologne]

GR: Do we want to make the changes to both <cmath> and <cstdlib>?
AM: I think so; we should provide consistent overloads.
GR: Then we're imposing restrictions on what users put in the global namespace.
AM: I'm not so worried about that. Users already know not to use C library names.
VV: So what are we going to do about unsigned integers? AM: We will say that they are ill-formed.
AM: Does anyone volunteer to send updated wording to Daniel? GR, can you do it? GR: Sure.
GR: To clarify: we want to make unsigned types ill-formed?
AM: With promotion rank at least unsigned int.
GR: And NL suggests to just list those types.

Conclusion: Merge the resolution into a single issue.

Previous resolution from Daniel [SUPERSEDED]:

This wording is relative to N3376.

  1. Change 26.8 [c.math] p11 as indicated:

    -11- Moreover, except for the abs functions, there shall be additional overloads sufficient to ensure:

    […]

[2015-03-03, Geoffrey Romer provides improved wording]

In the following I've drafted combined wording to resolve LWG 2192 and 2294. Note that the first two paragraphs are taken verbatim from the P/R of LWG 2294, but the third is newly drafted:

[2015-05-05 Lenexa: Howard to draft updated wording]

Proposed resolution:

This wording is relative to N4296.

  1. Insert the following new paragraphs after 26.8 [c.math] p7:

    -6- In addition to the int versions of certain math functions in <cstdlib>, C++ adds long and long long overloaded versions of these functions, with the same semantics.

    -7- The added signatures are:

    long abs(long); // labs()
    long long abs(long long); // llabs()
    ldiv_t div(long, long); // ldiv()
    lldiv_t div(long long, long long); // lldiv()
    

    -?- To avoid ambiguities, C++ also adds the following overloads of abs() to <cstdlib>, with the semantics defined in <cmath>:

    float abs(float);
    double abs(double);
    long double abs(long double);
    

    -?- To avoid ambiguities, C++ also adds the following overloads of abs() to <cmath>, with the semantics defined in <cstdlib>:

    int abs(int);
    long abs(long);
    long long abs(long long);
    

    -?- If abs() is called with an argument of unsigned integral type that cannot be converted to int by integral promotion (4.5 [conv.prom]), the program is ill-formed. [Note: arguments that can be promoted to int are permitted for compatibility with C. — end note]


2195. Missing constructors for match_results

Section: 28.10 [re.results] Status: Open Submitter: Daniel Krügler Opened: 2012-10-06 Last modified: 2015-05-22

View all other issues in [re.results].

View all issues with Open status.

Discussion:

The requirement expressed in 28.10 [re.results] p2

The class template match_results shall satisfy the requirements of an allocator-aware container and of a sequence container, as specified in 23.2.3 [sequence.reqmts], except that only operations defined for const-qualified sequence containers are supported.

can be read to require the existence of the described constructors from as well, but they do not exist in the synopsis.

The missing sequence constructors are:

match_results(initializer_list<value_type>);
match_results(size_type, const value_type&);
template<class InputIterator> match_results(InputIterator, InputIterator);

The missing allocator-aware container constructors are:

match_results(const match_results&, const Allocator&);
match_results(match_results&&, const Allocator&);

It should be clarified, whether (a) constructors are an exception of above mentioned operations or (b) whether at least some of them (like those accepting a match_results value and an allocator) should be added.

As visible in several places of the standard (including the core language), constructors seem usually to be considered as "operations" and they certainly can be invoked for const-qualified objects.

The below given proposed resolution applies only the minimum necessary fix, i.e. it excludes constructors from above requirement.

[2013-04-20, Bristol]

Check current implementations to see what they do and, possibly, write a paper.

[2013-09 Chicago]

Ask Daniel to update the proposed wording to include the allocator copy and move constructors.

[2014-01-18 Daniel changes proposed resolution]

Previous resolution from Daniel [SUPERSEDED]:

  1. Change 28.10 [re.results] p2 as indicated:

    The class template match_results shall satisfy the requirements of an allocator-aware container and of a sequence container, as specified in 23.2.3 [sequence.reqmts], except that only operations defined for const-qualified sequence containers that are not constructors are supported.

[2015-05-06 Lenexa]

MC passes important knowledge to EF.

VV, RP: Looks good.

TK: Second form should be conditionally noexcept

JY: Sequence constructors are not here, but mentioned in the issue writeup. Why?

TK: That would have been fixed by the superseded wording.

JW: How does this interact with Mike Spertus' allocator-aware regexes? [...] Perhaps it doesn't.

JW: Can't create match_results, want both old and new resolution.

JY: It's problematic that users can't create these, but not this issue.

VV: Why conditional noexcept?

MC: Allocator move might throw.

JW: Update superseded wording to "only non-constructor operations that are"?

MC: Only keep superseded, but append "and the means of constructing match_results are limited to [...]"?

JY: Bullet 4 paragraph 2 needs to address the allocator constructor.

Assigned to JW for drafting.

Proposed resolution:

This wording is relative to N3936.

  1. Change 28.10 [re.results] p4, class template match_results synopsis, as indicated:

    […]
    // 28.10.1, construct/copy/destroy:
    explicit match_results(const Allocator& a = Allocator());
    match_results(const match_results& m);
    match_results(const match_results& m, const Allocator& a);
    match_results(match_results&& m) noexcept;
    match_results(match_results&& m, const Allocator& a) noexcept;
    […]
    
  2. Change 28.10.1 [re.results.const] as indicated: [Drafting note: Paragraph 6 as currently written, makes not much sense, because the noexcept does not allow any exception to propagate. Further-on, the allocator requirements do not allow for throwing move constructors. Deleting it seems to be near to editorial — end drafting note]

    match_results(const match_results& m);
    match_results(const match_results& m, const Allocator& a);
    

    -4- Effects: Constructs an object of class match_results, as a copy of m.

    match_results(match_results&& m) noexcept;
    match_results(match_results&& m, const Allocator& a) noexcept;
    

    -5- Effects: Move-constructs an object of class match_results from m satisfying the same postconditions as Table 142. AdditionallyFor the first form, the stored Allocator value is move constructed from m.get_allocator().

    -6- Throws: Nothing if the allocator's move constructor throws nothing.


2198. max_load_factor(z) makes no strong guarantees, but bans useful behavior

Section: 23.2.5 [unord.req] Status: Open Submitter: Alisdair Meredith Opened: 2012-10-09 Last modified: 2015-04-08

View other active issues in [unord.req].

View all other issues in [unord.req].

View all issues with Open status.

Discussion:

The user cannot specify a max_load_factor for their unordered container at construction, it must be supplied after the event, when the container is potentially not empty. The contract for this method is deliberately vague, not guaranteeing to use the value supplied by the user, and any value actually used will be used as a ceiling that the container will attempt to respect.

The only guarantee we have is that, if user requests a max_load_factor that is less than the current load_factor, then the operation will take constant time, thus outlawing an implementation that chooses to rehash and so preserve as a class invariant that load_factor < max_load_factor.

Reasonable options conforming to the standard include ignoring the user's request if the requested value is too low, or deferring the rehash to the next insert operation and allowing the container to have a strange state (wrt max_load_factor) until then - and there is still the question of rehashing if the next insert is for a duplicate key in a unique container.

Given the deliberate vagueness of the current wording, to support a range of reasonable (but not perfect) behaviors, it is not clear why the equally reasonable rehash to restore the constraint should be outlawed. It is not thought that this is a performance critical operation, where users will be repeatedly setting low load factors on populated containers, in a tight or (less unlikely) an instant response scenario.

[2013-03-15 Issues Teleconference]

Moved to Open.

Alisdair to provide wording.

Proposed resolution:


2199. unordered containers are required to have an initial max load factor of 1.0

Section: 23.2.5 [unord.req] Status: Open Submitter: Alisdair Meredith Opened: 2012-10-09 Last modified: 2015-04-08

View other active issues in [unord.req].

View all other issues in [unord.req].

View all issues with Open status.

Discussion:

The default constructor, allocator-aware constructor, and range-based constructors for the unordered containers do not offer a means to control the initial max_load_factor, so the standard mandates the value 1.0. This seems overly restrictive, as there is plenty of research suggesting a value between 0.5 and 1.0 is more often optimal for unique-key containers, and perhaps a slightly higher value might be appropriate for multi-containers.

Rather than guess at the appropriate max_load_factor, it seems reasonable that the standard should allow vendors to pick a value at their discretion, with perhaps a note of advice. It is less clear whether the default value should be implementation-defined or unspecified, given the ease of a user determining this by querying this attribute immediately after construction.

[2013-03-15 Issues Teleconference]

Moved to Open.

Alisdair to provide wording.

Marshall: It seems to me that what you really want is to be able to pass a max load factor in the constructor, but that's a different issue.

Alisdair agrees in principle, but concerned with adding yet more constructors to these classes.

Proposed resolution:


2201. Missing macro entries from C standard library

Section: C.5 [diff.library] Status: New Submitter: Kevin McCarty Opened: 2012-02-03 Last modified: 2015-04-08

View all other issues in [diff.library].

View all issues with New status.

Discussion:

It seems that in C.5 [diff.library], Table 150 the following macros from 18.3.3 [c.limits], Table 31 are missing:

LLONG_MIN 
LLONG_MAX
ULLONG_MAX

In addition in C.5 [diff.library], Table 150 the following macros from 18.3.3 [c.limits], Table 32 are missing:

DECIMAL_DIG 
FLT_EVAL_METHOD

Furtheron it seems that in C.5 [diff.library], Table 149/150 further macros are missing as well, e.g. HUGE_VALF, INFINITY, etc.

[2014-02 Issaquah:]

This is an issue, all of C has not been updated for C99, C99 functions are missing, whole section needs to be overhauled.

The issue needs to be updated for functions and other missing items and when that happens the issue title is wrong and needs to be adapted.

Proposed resolution:


2202. Missing allocator support by async

Section: 30.6.8 [futures.async] Status: Deferred Submitter: Detlef Vollmann Opened: 2012-10-19 Last modified: 2015-05-08

View all other issues in [futures.async].

Discussion:

promise, packaged_task, and async are the only places where a shared state is actually supposed to be allocated. Accordingly, promise and packaged_task are "allocator-aware". But function template async provides no way to provide an allocator.

[2013-09 Chicago]

Matt: deprecate async

Nico: read my paper

Alisdair: defer issues to wait for polymorphic allocators

Alisdair: defer, active topic of research Deferred

[2014-02-20 Re-open Deferred issues as Priority 4]

[2015-05 Lenexa, SG1 response]

We want whatever status approximates: "will not fix; we're working on a replacement facility and don't want to add features to a broken one"

Proposed resolution:


2206. Inaccuracy in initializer_list constructor requirements

Section: 23.2.3 [sequence.reqmts], 23.2.4 [associative.reqmts], 23.2.5 [unord.req], 26.5.1.2 [rand.req.seedseq] Status: Open Submitter: Jeffrey Yasskin Opened: 2012-10-21 Last modified: 2015-04-08

View all other issues in [sequence.reqmts].

View all issues with Open status.

Discussion:

In 23.2.3 [sequence.reqmts] p3, we have "il designates an object of type initializer_list<value_type>", and then several functions that take 'il' as an argument. However, an expression like {1, 2, 'a'} is not an object of type initializer_list<int> unless it's used to initialize an explicitly-typed variable of that type. I believe we want:

std::vector<int> v;
v = {1, 2, 'a'};

to compile portably, so we should say something different when defining 'il'. The same phrasing happens in 23.2.4 [associative.reqmts], 23.2.5 [unord.req], and 26.5.1.2 [rand.req.seedseq].

This may just be an editorial issue because the actual class synopses declare the functions to take initializer_list<exact_type>.

[2013-03-15 Issues Teleconference]

Moved to Open.

This is definitely not NAD

Should copy the suggested wording as the proposed resolution.

Proposed resolution:


2208. std::reverse_iterator should be a literal type

Section: 24.5.1 [reverse.iterators] Status: New Submitter: Jeffrey Yasskin Opened: 2012-10-30 Last modified: 2015-04-08

View all other issues in [reverse.iterators].

View all issues with New status.

Discussion:

std::reverse_iterator::reverse_iterator(Iterator) should be constexpr so that other constexpr functions can return reverse_iterators. Of the other methods, the other constructors, base(), operator+, operator-, operator[], and the non-member operators can probably also be constexpr.

operator* cannot be constexpr because it involves an assignment to a member variable. Discussion starting with c++std-lib-33282 indicated that it would be useful to make reverse_iterator a literal type despite this restriction on its use at compile time.

Proposed resolution:


2214. Clarify basic_ios::init call restrictions

Section: 27.5.5.2 [basic.ios.cons] Status: Open Submitter: Andrey Semashev Opened: 2012-11-09 Last modified: 2015-04-08

View all other issues in [basic.ios.cons].

View all issues with Open status.

Discussion:

There is an ambiguity in how std::basic_ios::init method (27.5.5.2 [basic.ios.cons]) can be used in the derived class. The Standard only specify the state of the basic_ios object after the call completes. However, in basic_ios default constructor description (27.5.5.2 [basic.ios.cons]) there is this sentence:

Effects: Constructs an object of class basic_ios (27.5.3.7 [ios.base.cons]) leaving its member objects uninitialized. The object shall be initialized by calling basic_ios::init before its first use or before it is destroyed, whichever comes first; otherwise the behavior is undefined.

This restriction hints that basic_ios::init should be called exactly once before the object can be used or destroyed, because basic_ios::init may not know whether it was called before or not (i.e. whether its members are actually uninitialized or are initialized by the previous call to basic_ios::init). There is no such restriction in the basic_ios::init preconditions so it is not clear whether it is allowed to call basic_ios::init multiple times or not.

This problem has already affected publicly available implementations. For example, Microsoft Visual C++ STL introduces a memory leak if basic_ios::init is called multiple times, while GCC 4.7 and STLPort reinitialize the basic_ios object correctly without memory leak or any other undesired effects. There was a discussion of this issue on Boost developers mailing list, and there is a test case that reproduces the problem. The test case is actually a bug report for my Boost.Log library, which attempts to cache basic_ostream-derived objects internally to avoid expensive construction and destruction. My stream objects allowed resetting the stream buffer pointers the stream is attached to, without requiring to destroy and construct the stream.

My personal view of the problem and proposed resolution follows.

While apparently the intent of basic_ios::init is to provide a way to initialize basic_ios after default construction, I see no reason to forbid it from being called multiple times to reinitialize the stream. Furthermore, it is possible to implement a conforming basic_ios that does not have this restriction.

The quoted above section of the Standard that describes the effects of the default constructor is misleading. The Standard does not mandate any data members of basic_ios or ios_base (27.5.3 [ios.base]), which it derives from. This means that the implementation is allowed to use non-POD data members with default constructors that initialize the members with particular default values. For example, in the case of Microsoft Visual C++ STL the leaked memory is an std::locale instance that is dynamically allocated during basic_ios::init, a raw pointer to which is stored within ios_base. It is possible to store e.g. an unique_ptr instead of a raw pointer as a member of ios_base, the smart pointer will default initialize the underlying raw pointer on default construction and automatically destroy the allocated object upon being reset or destroyed, which would eliminate the leak and allow basic_ios::init to be called multiple times. This leads to conclusion that the default constructor of basic_ios cannot leave "its member objects uninitialized" but instead performs default initialization of the member objects, which would mean the same thing in case of POD types.

However, I feel that restricting ios_base and basic_ios members to non-POD types is not acceptable. Since multiple calls to basic_ios::init are not forbidden by the Standard, I propose to correct the basic_ios default constructor description so that it is allowed to destroy basic_ios object without calling basic_ios::init. This would imply that any raw members of basic_ios and ios_base should be initialized to values suitable for destruction (essentially, this means only initializing raw pointers to NULL). The new wording could look like this:

Effects: Constructs an object of class basic_ios (27.5.3.7 [ios.base.cons]) initializing its member objects to unspecified state, only suitable for basic_ios destruction. The object shall be initialized by calling basic_ios::init before its first use; otherwise the behavior is undefined.

This would remove the hint that basic_ios::init must be called exactly once. Also, this would remove the requirement for basic_ios::init to be called at all before the destruction. This is also an important issue because the derived stream constructor may throw an exception before it manages to call basic_ios::init (for example, if the streambuf constructor throws), and in this case the basic_ios destructor has undefined behavior.

To my mind, the described modification is sufficient to resolve the issue. But to emphasize the possibility to call basic_ios::init multiple times, a remark or a footnote for basic_ios::init postconditions could be added to explicitly state the semantics of calling it multiple times. The note could read as follows:

The function can be called multiple times during the object lifetime. Each subsequent call reinitializes the object to the described in postconditions initial state.

[2013-04-20, Bristol]

Alisdair: The current wording is unclear but the proposed resolution is wrong

Solution: Clarify that init must be called once and only once. Move then to review.

Proposed resolution:

This wording is relative to N3485.

  1. Edit 27.5.5.2 [basic.ios.cons] as indicated:

    basic_ios();
    

    -2- Effects: Constructs an object of class basic_ios (27.5.3.7 [ios.base.cons]) leaving its member objects uninitializedinitializing its member objects to unspecified state, only suitable for basic_ios destruction. The object shall be initialized by calling basic_ios::init before its first use or before it is destroyed, whichever comes first; otherwise the behavior is undefined.

    void init(basic_streambuf<charT,traits>* sb);
    

    Postconditions: The postconditions of this function are indicated in Table 128.

    -?- Remarks: The function can be called multiple times during the object lifetime. Each subsequent call reinitializes the object to the described in postconditions initial state.


2215. (unordered) associative container functors should be CopyConstructible

Section: 23.2.4 [associative.reqmts], 23.2.5 [unord.req] Status: Open Submitter: Alisdair Meredith Opened: 2012-11-14 Last modified: 2015-04-08

View other active issues in [associative.reqmts].

View all other issues in [associative.reqmts].

View all issues with Open status.

Discussion:

The requirements on the functors used to arrange elements in the various associative and unordered containers are given by a set of expressions in tables 102 — Associative container requirements, and 103 — Unordered associative container requirements. In keeping with Library convention these expressions make the minimal requirements necessary on their types. For example, we have the following 3 row extracts for the unordered containers:

Expression Assertion/note pre-/post-condition
X(n, hf, eq)
X a(n, hf, eq)
Requires: hasher and key_equal are CopyConstructible.
X(n, hf)
X a(n, hf)
Requires: hasher is CopyConstructible and key_equal is DefaultConstructible.
X(n)
X a(n)
Requires: hasher and key_equal are DefaultConstructible.

However, the signature for each class template requires that the functors must effectively be CopyConstructible for each of these expressions:

template <class Key,
          class T,
          class Hash  = hash<Key>,
          class Pred  = std::equal_to<Key>,
          class Allocator = std::allocator<std::pair<const Key, T> > >
class unordered_map
{
  ...

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

  ...
}

The letter of the standard can be honored as long as implementors recognize their freedom to split this one signature into multiple overloads, so that the documented default arguments (requiring a CopyConstructible functor) are not actually passed as default arguments.

As we look into the requirements for the copy constructor and copy-assignment operator, the requirements are even more vague, as the explicit requirements on the functors are not called out, other than saying that the functors are copied.

Must the functors be CopyAssignable? Or is CopyConstructible sufficient in this case? Do we require that the functors be Swappable so that the copy-swap idiom can be deployed here? Note that a type that is both CopyConstructible and CopyAssignable is still not guaranteed to be Swappable as the user may delete the swap function for their type in their own namespace, which would be found via ADL.

Some clean-up of the requirements table looks necessary, to at least document the assignment behavior. In addition, we should have clear guidance on whether these functors should always be CopyConstructible, as suggested by the class template definitions, or if the requirement tables are correct and we should explicitly split up the constructors in the (unordered) associative containers to no longer use default (function) arguments to obtain their defaulted functors.

I recommend the simplest solution would be to always require that the functors for (unordered) associative containers be CopyConstructible, above the requirements tables themselves, so that the issue need not be addressed within the tables. I suggest that the assignment operators for these containers add the requirement that the functors be Swappable, rather than forwarding the corresponding Assignable requirement.

[2013-03-15 Issues Teleconference]

Moved to Open.

Alisdair to propose wording.

[2014-06-08, Daniel comments]

The area of this issue partially overlaps what LWG 2227 addresses.

Proposed resolution:


2216. regex_replace(basic_string) allocator handling

Section: 28.11.4 [re.alg.replace] Status: New Submitter: Jeffrey Yasskin Opened: 2012-11-26 Last modified: 2015-04-08

View all other issues in [re.alg.replace].

View all issues with New status.

Discussion:

template <class traits, class charT, class ST, class SA>
  basic_string<charT, ST, SA>
  regex_replace(const basic_string<charT, ST, SA>& s,
      const basic_regex<charT, traits>& e,
      const charT* fmt,
      regex_constants::match_flag_type flags = 
	    regex_constants::match_default);

and friends are documented as

Constructs an empty string result of type basic_string<charT, ST, SA> and calls regex_replace(back_inserter(result), s.begin(), s.end(), e, fmt, flags).

This appears to require the result to have a default-constructed allocator, which isn't even possible for all allocator types. I suspect the allocator should be copied from 's' instead. Possibly there should be an additional defaulted argument to override the allocator of the result.

Proposed resolution:


2220. Under-specification of operator== for regex_token_iterator

Section: 28.12.2.2 [re.tokiter.comp] Status: New Submitter: Pete Becker Opened: 2012-11-21 Last modified: 2015-04-08

View all issues with New status.

Discussion:

Consider the following example:

std::string str0("x");
std::regex rg0("a");
std::regex_token_iterator it0(str0.begin(), str0.end(), rg0, -1); // points at "x" in str0
std::string str1("x");
std::regex rg1("b");
std::regex_token_iterator it1(str1.begin(), str1.end(), rg1, -1); // points at "x" in str1

28.12.2.2 [re.tokiter.comp] p1 says that it0.operator==(it1) returns true "if *this and right are both suffix iterators and suffix == right.suffix"; both conditions are satisfied in this example. It does not say that they must both be iterators into the same sequence, nor does it say (as general iterator requirements do) that they must both be in the domain of == in order for the comparison to be meaningful. It's a simple statement: they're equal if the strings they point at compare equal. Given this being a valid comparison, the obtained result of "true" looks odd.

The problem is that for iterator values prior to the suffix iterator, equality means the same regular expression and the same matched sequence (both uses of "same" refer to identity, not equality); for the suffix iterator, equality means that the matched sequences compare equal.

Proposed resolution:


2221. No formatted output operator for nullptr

Section: 27.7.3 [output.streams] Status: New Submitter: Matt Austern Opened: 2012-12-07 Last modified: 2015-04-08

View all issues with New status.

Discussion:

When I write

std::cout << nullptr << std::endl;

I get a compilation error, "ambiguous overload for 'operator<<' in 'std::cout << nullptr'". As far as I can tell, the compiler is right to issue that error. There are inserters for const void*, const char*, const signed char*, and const unsigned char*, and none for nullptr_t, so the expression really is ambiguous.

Proposed wording:

The obvious library solution is to add a nullptr_t overload, which would be defined something like

template<class C, class T>
basic_ostream<C, T>& operator<<(basic_ostream<C, T>& os, nullptr_t) 
{ 
  return os << (void*) nullptr; 
}

We might also consider addressing this at a core level: add a special-case language rule that addresses all cases where you write f(nullptr) and f is overloaded on multiple pointer types. (Perhaps a tiebreaker saying that void* is preferred in such cases.)

Proposed resolution:


2223. shrink_to_fit effect on iterator validity

Section: 23.3.6.3 [vector.capacity] Status: Open Submitter: Juan Soulie Opened: 2012-12-17 Last modified: 2015-04-08

View other active issues in [vector.capacity].

View all other issues in [vector.capacity].

View all issues with Open status.

Discussion:

After the additions by 2033, it appears clear that the intended effect includes a reallocation and thus the potential effect on iterators should be explicitly added to the text in order to not contradict 23.2.1 [container.requirements.general]/11, or at the very least, explicitly state that a reallocation may happen.

Taking consistency with "reserve" into consideration, I propose:

BTW, while we are at it, I believe the effect on iterators should also be explicitly stated in the other instance a reallocation may happen: 23.3.6.5 [vector.modifiers]/1 — even if obvious, it only contradicts 23.2.1 [container.requirements.general]/11 implicitly.

I propose to also insert "Reallocation invalidates all the references, pointers, and iterators referring to the elements in the sequence." at the appropriate location in its "Remarks".

[2012-12-19: Jonathan Wakely comments]

The described problem also affects std::basic_string and std::deque.

[2013-03-15 Issues Teleconference]

Moved to Review.

[2013-04-18, Bristol]

Daniel extends the P/R.

Rationale:

The wording in 21.4.4 [string.capacity] combined with 21.4.1 [string.require] seems to say the necessary things. We cannot impose all requirements as we do for vector, because we want to allow the short-string-optimization.

[2014-02-15 post-Issaquah session]

STL: I think that shrink_to_fit should be a no-op when called twice.

STL: Do we ever define reallocation for deque? Nope, all mentions of "reallocation" are in vector. We define what it means in vector::reserve(), but not for deque.

STL: Oh duh, they define reallocate in the PR. But I think we can do better here.

STL: Optimally, deque shrinking just allocates a new map of pointers, and drops empty blocks, but preserves pointers/references to elements.

Alisdair: That's like unordered containers, invalidating only iterators.

Pablo: It doesn't make sense to reduce capacity() to size(), because deque doesn't have capacity!

STL: For vector, "effectively reduces the capacity" is unnecessary, the capacity there is observable.

STL: There is a strong reason to provide an optimal shrink to fit for deque, since only the library implementer can do this.

STL: The other thing I don't like the repeated definition of reallocation for vector, we define it once and use it in a bunch of places. At most we can lift it up to the vector synopsis.

STL: I'll write new wording.

[2014-10-01, STL adds discussion and provides new wording]

Compared to the previous proposed resolution:

My wording doesn't directly say that shrink_to_fit() should be a no-op when called twice in a row. (Indirectly, if the first call reduces capacity() to size(), the second call must preserve iterators/etc.) I considered rewording the complexity to say "linear if reallocation happens", but that's potentially problematic (what if we copy almost all N elements, then one throws and we have to unwind? There are no effects, so reallocation didn't happen, yet we took longer than constant time). Implementers can always do better than the stated complexity bounds.

I chose not to modify deque's requirements, so implementations remain free to reallocate the elements themselves.

I didn't attempt to centralize vector's reallocation wording. That can be done editorially, if someone is sufficiently motivated.

Previous resolution from Juan Soulie/Daniel [SUPERSEDED]:

This wording is relative to N3485.

  1. Keep 21.4.4 [string.capacity] around p14 unchanged, because we don't speak about reallocations and we give the strong exception guarantee in 21.4.1 [string.require] (Invalidation specification also at that place):

    void shrink_to_fit();
    

    -14- Remarks: shrink_to_fit is a non-binding request to reduce capacity() to size(). [Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note ].

  2. Edit 23.3.3.3 [deque.capacity] around p7 as indicated:

    void shrink_to_fit();
    

    -5- Requires: T shall be MoveInsertable into *this.

    -?- Effects: shrink_to_fit is a non-binding request to reduce capacity() to size(). [Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note ] Reallocation happens at this point if and only if the function effectively reduces the capacity. If an exception is thrown other than by the move constructor of a non-CopyInsertable T there are no effects.

    -6- Complexity: Linear in the size of the sequence.

    -7- Remarks: shrink_to_fit is a non-binding request to reduce capacity() to size(). [Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note ] If an exception is thrown other than by the move constructor of a non-CopyInsertable T there are no effects.Reallocation invalidates all the references, pointers, and iterators referring to the elements in the sequence.

  3. Edit 23.3.6.3 [vector.capacity] around p7 as indicated:

    void shrink_to_fit();
    

    -7- Requires: T shall be MoveInsertable into *this.

    -?- Effects: shrink_to_fit is a non-binding request to reduce capacity() to size(). [Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note ] Reallocation happens at this point if and only if the function effectively reduces the capacity. If an exception is thrown other than by the move constructor of a non-CopyInsertable T there are no effects.

    -8- Complexity: Linear in the size of the sequence.

    -9- Remarks: shrink_to_fit is a non-binding request to reduce capacity() to size(). [Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note ] If an exception is thrown other than by the move constructor of a non-CopyInsertable T there are no effects.Reallocation invalidates all the references, pointers, and iterators referring to the elements in the sequence.

  4. Edit 23.3.6.5 [vector.modifiers] p1 as indicated:

    iterator insert(const_iterator position, const T& x);
    iterator insert(const_iterator position, T&& x);
    iterator insert(const_iterator position, size_type n, const T& x);
    template <class InputIterator>
    iterator insert(const_iterator position, InputIterator first, InputIterator last);
    iterator insert(const_iterator position, initializer_list<T>);
    template <class... Args> void emplace_back(Args&&... args);
    template <class... Args> iterator emplace(const_iterator position, Args&&... args);
    void push_back(const T& x);
    void push_back(T&& x);
    

    -1- Remarks: Causes reallocation if the new size is greater than the old capacity. Reallocation invalidates all the references, pointers, and iterators referring to the elements in the sequence. If no reallocation happens, all the iterators and references before the insertion point remain valid. If an exception is thrown other than by the copy constructor, move constructor, assignment operator, or move assignment operator of T or by any InputIterator operation there are no effects. If an exception is thrown by the move constructor of a non-CopyInsertable T, the effects are unspecified.

[2015-02, Cologne]

GR: I'm concerned that shrink_to_fit may cause reallocation without changing the capacity. […] It's about correctness. The statement about invalidation is useless if I cannot detect whether reallocation has happened?

AM: It seems like the logic goes the other way round: It's the capacity change that causes reallocation, so if there's no capacity change, there's no reallocation. But that's not quite how I'd like to say it... maybe this, : "If capacity does not change, no reallocation occurs."

GR: Where does it actually say that reserve() invalidates? AM: It should say that in the container requirements. VV: vector specifies in reserve that there's reallocation if and only if the capacity changes. GR: I can't find anything in the container requirements about reserve. DK: No, it's specified for every container separately. GR: It isn't specified for string.

GR: I'm noticing that the issue touches on shrink_to_fit for a bunch of containers. Anyway, I think the reserve issue [re string] is in scope for this issue. This change is touching on a lot of members.

AM: Landing this change will provide clarity for what we should do with basic_string. GR: We're already asking for changes; we should fix string as well. AM: If one of the changes is ready before the other, I'd like to land the finished part first, but if both are ready for Lenexa, I'm equally happy to fix them in one go.

DK will reword this.

Conclusion: Update wording, revisit in Lenexa.

Proposed resolution:

This wording is relative to N3936.

  1. Change 21.4.4 [string.capacity] p14 as depicted:

    void shrink_to_fit();
    

    -14- RemarksEffects: shrink_to_fit is a non-binding request to reduce capacity() to size(). [Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note] It does not increase capacity(), but may reduce capacity() by causing reallocation.

    -?- Complexity: Linear in the size of the sequence.

    -?- Remarks: Reallocation invalidates all the references, pointers, and iterators referring to the elements in the sequence. If no reallocation happens, they remain valid.

  2. Change 23.3.3.3 [deque.capacity] p5-p7 as depicted:

    void shrink_to_fit();
    

    -5- Requires: T shall be MoveInsertable into *this.

    -?- Effects: shrink_to_fit is a non-binding request to reduce memory use but does not change the size of the sequence. [Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note] If an exception is thrown other than by the move constructor of a non-CopyInsertable T there are no effects.

    -6- Complexity: Linear in the size of the sequence.

    -7- Remarks: shrink_to_fit is a non-binding request to reduce memory use but does not change the size of the sequence. [Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note]shrink_to_fit invalidates all the references, pointers, and iterators referring to the elements in the sequence.

  3. Change 23.3.6.3 [vector.capacity] p7-p9 as depicted:

    void shrink_to_fit();
    

    -7- Requires: T shall be MoveInsertable into *this.

    -?- Effects: shrink_to_fit is a non-binding request to reduce capacity() to size(). [Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note] It does not increase capacity(), but may reduce capacity() by causing reallocation. If an exception is thrown other than by the move constructor of a non-CopyInsertable T there are no effects.

    -8- Complexity: Linear in the size of the sequence.

    -9- Remarks: shrink_to_fit is a non-binding request to reduce capacity() to size(). [Note: The request is non-binding to allow latitude for implementation-specific optimizations. — end note] If an exception is thrown other than by the move constructor of a non-CopyInsertable T there are no effects.Reallocation invalidates all the references, pointers, and iterators referring to the elements in the sequence. If no reallocation happens, they remain valid.

  4. Change 23.3.6.5 [vector.modifiers] p1 as depicted:

    -1- Remarks: Causes reallocation if the new size is greater than the old capacity. Reallocation invalidates all the references, pointers, and iterators referring to the elements in the sequence. If no reallocation happens, all the iterators and references before the insertion point remain valid. […]


2227. Stateful comparison objects in associative containers

Section: 23.2.4 [associative.reqmts] Status: Open Submitter: Juan Soulie Opened: 2012-12-19 Last modified: 2015-05-22

View other active issues in [associative.reqmts].

View all other issues in [associative.reqmts].

View all issues with Open status.

Discussion:

Table 102 in 23.2.4 [associative.reqmts]/8 states on expression a.key_comp() that it "returns the comparison object out of which a was constructed". At the same time, 23.2.1 [container.requirements.general]/8 states (starting in the third line) that "...Any Compare, Pred, or Hash objects belonging to a and b shall be swappable and shall be exchanged by unqualified calls to non-member swap...". This is problematic for any compliant implementation, since once swapped the container cannot return the comparison object out of which it was constructed unless incurring in storing an otherwise needless object.

The simple solution is to correct that statement in Table 102, but I believe this is part of a larger problem of underspecified behavior: The new standard has made an effort in regards to allocators and now fully specifies what happens to stateful allocator objects. It has even specified what happens to stateful hasher and key_equal members of unordered containers (they propagate), but it says nothing about stateful comparison objects of (ordered) associative containers, except for the statement in 23.2.1 [container.requirements.general]/8 referred above and only related to swap.

For example, it is unclear to me what is specified to happen on an assignment: should the comparison object be copied/moved along with the elements, or should the left-hand side object keep its own? Maybe this has been intentionally left unspecified with the purpose of compatibility with C++98, which I understand it specified that comparison objects were kept for the entire life of the container (like allocators) — an unfortunate choice. But anyway, the segment of 23.2.1 [container.requirements.general] quoted above seems to break any possible backwards compatibility with C++98 in this regard.

Therefore, taking into consideration consistency with how this is dealed with for unordered associative containers, I propose that Table 102 is modified as follows:

[2013-03-15 Issues Teleconference]

Moved to Review.

[2013-04-18, Bristol]

STL: can't believe we don't specify this already. this is totally necessary

Alisdair: how does it do this? copy construction? assignment?

Also need it for move.

STL: we already specify this for constructing from a comparator, not during copy construction though.

Jonathan: don't like wording, should say "key_compare is CopyConstructible. Uses b.key_comp() as a comparison object."

STL: we get it right for unordered!

Jonathan: can't wordsmith this now, but I think implementations do the right thing.

Alisdair: not sure what right thing is for moves. Also we say nothing about propagating allocators to functors.

Moved to Open.

[2015-02 Cologne]

TK: There's no need for fine-grained propagate/not-propagate control. If you don't want to propagate the predicate, you can simply construct or insert from an iterator range.

VV: libstdc++ already implements the resolution of this issue.

GR: There are a couple of other problems. We don't specify move constructor and move assignment for maps. Those are just general.

TK: General container requirements already describe the semantics for {copy,move}-{construction,assignment}, so it doesn't seem that there's room for choice in std::map assignments. unordered_map is different, though.

[Note: Check what general container requirements say about container equality.]

DK will draft wording. The decision is to unambiguously make all {copy,move}-{construction,assignment} operations endow the LHS with the exact state of the RHS, including all predicates and hash function states.

Conclusion: Update wording, revisit later.

[2015-05-06 Lenexa: Waiting for updated wording]

Proposed resolution:

This wording is relative to N3485.

  1. Change Table 102 as indicated:

    Table 102 — Associative container requirements (in addition to container)
    Expression Return type Assertion/note pre-/post-condition Complexity
    X(il) Same as X(il.begin(), il.end()). same as X(il.begin(), il.end()).
    X(b)
    X a(b)
    Copy constructor. In addition to
    the requirements of Table 96, copies
    the comparison object.
    Linear in b.size()
    a = b X& Copy assignment operator. In addition to
    the requirements of Table 96, copies the
    comparison object.
    Linear in a.size() and b.size()
    a.key_comp() X::key_compare rReturns thea's comparison object
    out of which a was constructed.
    constant

2234. assert() should allow usage in constant expressions

Section: 19.3 [assertions] Status: Open Submitter: Daniel Krügler Opened: 2013-01-12 Last modified: 2015-05-22

View other active issues in [assertions].

View all other issues in [assertions].

View all issues with Open status.

Discussion:

It is unclear from the current specification whether assert() expressions can be used in (potential) constant expressions. As an example consider the implementation of a constexpr function:

#include <cassert>

template<class T, unsigned N>
struct array {
  T data[N];
  constexpr const T& operator[](unsigned i) const {
    return assert(i < N), data[i];
  }
};

int main() {
  constexpr array<int, 3> ai = {1, 2, 3};
  constexpr int i = ai[0];
  int j = ai[0];
  // constexpr int k = ai[5];
}

The first question is whether this program is guaranteed well-formed? A second question is whether is would guaranteed to be ill-formed, if we uncomment the last code line in main()?

The wording in 19.3 [assertions] doesn't add anything significant to the C99 wording. From the C99 specification (7.2 p1 and 7.2.1.1 p2) we get already some valuable guarantees:

The current wording does not yet guarantee that assert expressions can be used in constant expressions, but all tested implementations (gcc, MSVC) would already support this use-case. It seems to me that this should be possible without giving assert a special meaning for the core language.

As a related comment it should be added, that there is a core language proposal that intents to relax some current constraints for constexpr functions and literal types. The most interesting one (making void a literal types and allowing for expression-statements) would simplify the motivating example implementation of operator[] to:

constexpr const T& operator[](unsigned i) const {
  assert(i < N);
  return data[i];
};

[2013-03-15 Issues Teleconference]

Moved to Open.

We are still gaining experience with constexpr as a language feature, and there may be work in Evolution that would help address some of these concerns. Defer discussion until we have a group familiar with any evolutionary direction.

[2014-06-08, Daniel comments and suggests wording]

After approval of N3652, void is now a literal type and constexpr functions can contain multiple statements, so this makes the guarantee that assert expressions are per-se constexpr-friendly even more relevant. A possible wording form could be along the lines of:

For every core constant expression e of scalar type that evaluates to true after being contextually converted to bool, the expression assert(e) shall be a prvalue core constant expression of type void.

Richard Smith pointed out some weaknesses of this wording form, for example it would not guarantee to require the following example to work:

constexpr void check(bool b) { assert(b); }

because b is not a core constant expression in this context.

He suggested improvements that lead to the wording form presented below (any defects mine).

[Lenexa 2015-05-05]

MC : ran into this

Z : Is it guaranteed to be an expression?

MC : clarifies that assert runs at runtime, not sure what it does at compile time

STL : c standard guarantees its an expression and not a whole statement, so comma chaining it is ok

HH : Some implementations work as author wants it to

STL : also doing this as constexpr

DK/STL : discussing how this can actually work

HH : GCC 5 also implements it. We have implementor convergence

MC : Wants to do this without giving assert a special meaning

STL : NDEBUG being defined where assert appears is not how assert works. This is bug in wording. Should be "when assert is defined" or something like that. ... is a constant subexpression if NDEBUG is defined at the point where assert is last defined or redefined."

Would like to strike the "either" because ok if both debug or assertion is true. We want inclusive-or here

MC : is redefined needed?

STL : my mental model is its defined once and then redefined

HH : wants to up to P2

Z/STL : discussing how wording takes care of how/when assert is defined/redefefined

STL/WB : discussing whether to move to ready or review. -> Want to move it to ready.

ask for updated wording

p3 -> p2

plan to go to ready after checking wording

Proposed resolution:

This wording is relative to N3936.

  1. Introduce the following new definition to the existing list in 17.3 [definitions]: [Drafting note: If LWG 2296 is accepted before this issue, the accepted wording for the new definition should be used instead — end drafting note]

    constant subexpression [defns.const.subexpr]

    an expression whose evaluation as subexpression of a conditional-expression CE (5.16 [expr.cond]) would not prevent CE from being a core constant expression (5.20 [expr.const]).

  2. Insert a new paragraph following 19.3 [assertions] p1 as indicated:

    -?- An expression assert(E) is a constant subexpression ( [defns.const.subexpr]), if either

    • NDEBUG is defined at the point where assert(E) appears, or

    • E contextually converted to bool (4 [conv]), is a constant subexpression that evaluates to the value true.


2237. <cuchar> macros

Section: 21.8 [c.strings] Status: New Submitter: Jason Merrill Opened: 2013-01-29 Last modified: 2015-04-08

View other active issues in [c.strings].

View all other issues in [c.strings].

View all issues with New status.

Discussion:

Apparently C1X changes __STDC_UTF_16__ and __STDC_UTF_32__ from macros defined in uchar.h (and reflected in C++ by Table 79) to be predefined by the compiler. Do we want to do the same?

Proposed resolution:


2238. Problematic iterator-pair constructor of containers

Section: 21.8 [c.strings] Status: Open Submitter: Johannes Schaub Opened: 2013-02-02 Last modified: 2015-04-08

View other active issues in [c.strings].

View all other issues in [c.strings].

View all issues with Open status.

Discussion:

The non-explicit nature of the iterator-pair constructor of containers, such a

template <class InputIterator>
vector(InputIterator first, InputIterator last, const Allocator& = Allocator());

can be selected in unexpected situations, leading to a hard runtime error, as demonstrated by the following example:

#include <vector>

void f(std::vector<char> v){ /* ... */}

int main() {
  f({"A", "B"});
}

The actually intended initializer-list constructor isn't feasible here, so the best match is the constructor template

template <class InputIterator>
vector(InputIterator first, InputIterator last, const Allocator& = Allocator());

This compiles, but will result in code running amok. The potential trap (that cannot be easily detected by the library implementation) could be reduced by making this constructor explicit. It would still have the effect to be selected here, but the code would be ill-formed, so the programmer gets a clear meassage here.

[2014-06 Rapperswil]

JW: can't fix this, don't want to touch this, Do The Right Thing clause has been a source of tricky issues. only really happens with string literals, that's the only way to create an array that isn't obviously an array

GR: want to see paper

AM: is it only string literals, or also UDLs?

STL: maybe, but we don't need to deal with that. This is only a problem in a very specific case

Leave as Open.

Proposed resolution:


2241. <cstdalign> and #define of alignof

Section: 18.10 [support.runtime] Status: Open Submitter: Richard Smith Opened: 2013-02-14 Last modified: 2015-04-08

View other active issues in [support.runtime].

View all other issues in [support.runtime].

View all issues with Open status.

Discussion:

According to 18.10 [support.runtime] p2:

The contents of these headers are the same as the Standard C library headers [..], <stdalign.h>, [..]

Since our base C standard is C99, which doesn't have a <stdalign.h>, the reference to a non-existing C header is irritating (In this context <stdalign.h> doesn't refer to the deprecated C++ header <stdalign.h> described in D.5 [depr.c.headers]).

Furthermore, it would be also important that it doesn not define a macro named alignof, which C11 also defines in this header.

Currently we only have the following guarantee as part of 18.10 [support.runtime] p7:

The header <cstdalign> and the header <stdalign.h> shall not define a macro named alignas.

It is unclear what the better strategy is: Striking the reference to <stdalign.h> in 18.10 [support.runtime] p2 or upgrading to C11 as new base C standard.

[2014-02-15 Issaquah]

STL: related to earlier issue on C4, 2201, and now we get a C11 header

JY: find _Alignof as keyword C11 FDIS has four defines in stdalign.h

AM: need paper for C11 as base library we should really do that

STL: really need vendor input

STL: don't think we need to do anything right now not P1

AM: any objections to downscale to P2 (no objections)

Proposed resolution:


2242. [uninitialized_]copy_n() defect

Section: 25.3.1 [alg.copy], 20.7.12.2 [uninitialized.copy] Status: New Submitter: Sean Parent Opened: 2013-02-14 Last modified: 2015-04-08

View other active issues in [alg.copy].

View all other issues in [alg.copy].

View all issues with New status.

Discussion:

copy_n() and uninitialized_copy_n() only return the output iterator, and not the input iterator. Likely the interface was simply copied from the original STL. Unfortunately the interface in the original STL contains a bug.

copy_n() and uninitialized_copy_n() must return the resulting input iterator as well as the output iterator (I would suggest returning a pair). Without this, there is no way to continue reading from an actual input iterator — and if it is really a forward iterator, it will cost n increments to get back to where you were.

Proposed resolution:


2243. istream::putback problem

Section: 27.7.2.3 [istream.unformatted] Status: New Submitter: Juan Soulie Opened: 2013-03-01 Last modified: 2015-04-08

View other active issues in [istream.unformatted].

View all other issues in [istream.unformatted].

View all issues with New status.

Discussion:

In 27.7.2.3 [istream.unformatted] / 34, when describing putback, it says that "rdbuf->sputbackc()" is called. The problem are not the obvious typos in the expression, but the fact that it may lead to different interpretations, since nowhere is specified what the required argument to sputbackc is.

It can be guessed to be "rdbuf()->sputbackc(c)", but "rdbuf()->sputbackc(char_type())" or just anything would be as conforming (or non-confoming) as the first guess.

Proposed resolution:


2245. packaged_task::reset() memory allocation

Section: 30.6.9.1 [futures.task.members] Status: Open Submitter: Jonathan Wakely Opened: 2013-03-05 Last modified: 2015-05-08

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

View all issues with Open status.

Discussion:

The effects of packaged_task::reset() result in memory allocation, but don't allow a user to provide an allocator.

packaged_task::reset() needs to be overloaded like so:

template<class Alloc>  
void reset(const Alloc&);

Alternatively, the effects of reset() need to require the same allocator is used as at construction, which would require the constructor to store the allocator for later use.

I like to remark that GCC at the moment uses the second option, i.e. the allocator passed to the constructor (if any) is used to create the new shared state, because this didn't require any change to the interface.

[2015-02 Cologne]

Handed over to SG1.

[2015-05 Lenexa, SG1 response]

No strong opinions in SG1, and this is really an LWG issue. Back to you.

Proposed resolution:


2248. numeric_limits::is_iec559 misnamed

Section: 18.3.2 [limits] Status: New Submitter: Pete Becker Opened: 2013-03-08 Last modified: 2015-04-08

View all other issues in [limits].

View all issues with New status.

Discussion:

This member should probably be named "is_ieee754". Or at least the standard should explain that IEC-559 no longer exists, and that it's been superseded by IEEE-754.

Proposed resolution:


2254. [arrays.ts] Is dynarray an allocator-aware container?

Section: 23.2.1 [container.requirements.general] Status: Open Submitter: Jonathan Wakely Opened: 2013-04-23 Last modified: 2015-04-08

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

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

View all issues with Open status.

Discussion:

Addresses: arrays.ts

23.2.1 [container.requirements.general] p3 says:

"All of the containers defined in this Clause and in (21.4) except array meet the additional requirements of an allocator-aware container, as described in Table 99."

Is this true of dynarray? I believe the answer must be no because dynarray has no allocator_type, and morally should be no, so that operations are defined in terms of std::allocator<T>, which p13 says doesn't actually need to be used (which allows the elements to be default-initialized as is intended, rather than "default-inserted into the container" using an allocator.)

The requirement that "each element is constructed with uses-allocator construction" provides roughly equivalent behaviour to the "CopyInsertable into X" requirements for allocator-aware containers, allowing an allocator to control construction of the dynarray elements.

[2013-09 Chicago]

Move to Deferred. This feature will ship after C++14 and should be revisited then.

[2014-06-06 pre-Rapperswill]

This issue has been reopened as arrays-ts.

Proposed resolution:

  1. Change to 23.2.1 [container.requirements.general] p13:

    -13- All of the containers defined in this Clause and in (21.4) except array and dynarray meet the additional requirements of an allocator-aware container, as described in Table 99.


2256. On vector iterator invalidation

Section: 23.3.6.5 [vector.modifiers] Status: New Submitter: Howard Hinnant Opened: 2013-04-29 Last modified: 2015-04-08

View other active issues in [vector.modifiers].

View all other issues in [vector.modifiers].

View all issues with New status.

Discussion:

23.3.6.5 [vector.modifiers]/p3 says:

iterator erase(const_iterator position);
iterator erase(const_iterator first, const_iterator last);

Effects: Invalidates iterators and references at or after the point of the erase.

Consider this example:

#include <vector>
#include <cassert>

int main()
{
  typedef std::vector<int> C;
  C c = {1, 2, 3, 4};
  C::iterator i = c.begin() + 1;
  C::iterator j = c.end() - 1;
  assert(*i == 2);
  assert(*j == 4);
  c.erase(c.begin());
  assert(*i == 3); // Why is this not perfectly fine?!
}

Why has the iterator i been invalidated? It still refers to a perfectly reasonable, fully constructed object. If vector::iterator were to be implemented as a pointer (which is legal), it is not possible for that last line to do anything but run fine.

The iterator j on the other hand now points at end, and any iterators that may now point beyond end(), into uninitialized memory, are clearly invalid.

But why do we say that an iterator that must point to a valid object is invalid? This looks to me like we simply got sloppy in our specification.

Proposed resolution:


2260. Missing requirement for Allocator::pointer

Section: 17.6.3.5 [allocator.requirements] Status: Open Submitter: Jonathan Wakely Opened: 2013-05-14 Last modified: 2015-04-08

View other active issues in [allocator.requirements].

View all other issues in [allocator.requirements].

View all issues with Open status.

Discussion:

For an allocator A<T> which defines A<T>::pointer to a class type, i.e. not T*, I see no requirement that A<T>::pointer is convertible to A<U>::pointer, even if T* is convertible to U*. Such conversions are needed in containers to convert from e.g. ListNodeBase* to ListNode<T>*.

The obvious way to do such conversions appears to be pointer_traits::pointer_to(), but that's ill-formed if the static member function A<T>::pointer::pointer_to() doesn't exist and the allocator requirements don't mention that function, so you need to cast A<T>::pointer to A<T>::void_pointer then cast that to A<U>::pointer.

Is converting via void_pointer really intended, or are we missing a requirement that pointer_traits<A<T>::pointer>::pointer_to() be well-formed?

Proposed resolution:

Add to the Allocator requirements table the following requirement:

The expression pointer_traits<XX::pointer>::pointer_to(r) is well-defined.

[2013-09 Chicago]

Pablo to come back with Proposed Wording

Proposed resolution:

  1. Edit Table 28 as indicated:

    Table 28 — Allocator requirements (continued)
    Expression Return type Assertion/note pre-/post-condition Default
    static_cast<X::const_pointer>(z) X::const_pointer static_cast<X::const_pointer>(z) == q  
    pointer_traits<X::pointer>::pointer_to(r) X::pointer    

2261. Are containers required to use their 'pointer' type internally?

Section: 23.2 [container.requirements] Status: New Submitter: Jonathan Wakely Opened: 2013-05-14 Last modified: 2015-04-08

View other active issues in [container.requirements].

View all other issues in [container.requirements].

View all issues with New status.

Discussion:

Is a container C only supposed to refer to allocated memory (blocks of contiguous storage, nodes, etc.) through objects of type C::pointer rather than C::value_type*?

I don't see anything explicitly requiring this, so a container could immediately convert the result of get_allocator().allocate(1) to a built-in pointer of type value_type* and only deal with the built-in pointer until it needs to deallocate it again, but that removes most of the benefit of allowing allocators to use custom pointer types.

[2014-06-12, Jonathan comments]

This issue is basically the same issue as LWG 1521, which agrees it's an issue, to be dealt with in the future, so I request that 2261 not be closed as a dup unless we reopen 1521.

Proposed resolution:


2262. Requirement for unique_ptr<T>::get_deleter()(p) to be able to destroy the unique_ptr

Section: 20.8.1.2 [unique.ptr.single] Status: Open Submitter: Rob Desbois Opened: 2013-05-15 Last modified: 2015-05-08

View all other issues in [unique.ptr.single].

View all issues with Open status.

Discussion:

N3337 20.8.1.2.5 [unique.ptr.single.modifiers] contains 2 non-normative notes stating:

[para 4]: "The order of these operations is significant because the call to get_deleter() may destroy *this."

[para 5]: "The postcondition does not hold if the call to get_deleter() destroys *this since this->get() is no longer a valid expression."

It seems this wording was created to resolve 998 due to the possibility that a unique_ptr may be destroyed through deletion of its stored pointer where that directly or indirectly refers to the same unique_ptr. If unique_ptr is required to support circular references then it seems this must be normative text: an implementation is currently allowed to operate on *this after the assignment and deletion specified in para 4, since this is only 'disallowed' by the non-normative note.

I propose the following draft rewording:

[para 4]: Effects: assigns p to the stored pointer, and then if the old value of the stored pointer, old_p, was not equal to nullptr, calls get_deleter()(old_p). No operation shall be performed after the call to get_deleter()(old_p) that requires *this to be valid, because the deletion may destroy *this if it is referred to directly or indirectly by the stored pointer. [Note: The order of these operations is significant because the call to get_deleter() may destroy *this. — end note]

[para 5]: Postconditions: If the call get_deleter()(old_p) destroyed *this, none. Otherwise, get() == p. [Note: The postcondition does not hold if the call to get_deleter() destroys *this since this->get() is no longer a valid expression. — end note]

I expect it will also be necessary to amend the requirements for a deleter, so in addition:

20.8.1.2 [unique.ptr.single] [para 1]: The default type for the template parameter D is default_delete. A client-supplied template argument D shall be a function object type (20.10), lvalue-reference to function, or lvalue-reference to function object type for which, given a value d of type D and a value ptr of type unique_ptr<T, D>::pointer, the expression d(ptr) is valid and has the effect of disposing of the pointer as appropriate for that deleter. Where D is not an lvalue reference type, d(ptr) shall be valid if ptr refers directly or indirectly to the invoking unique_ptr object.

[2013-10-05, Stephan T. Lavavej comments and provides alternative wording]

In Chicago, we determined that the original proposed change to 20.8.1.2 [unique.ptr.single]/1 was insufficient, because d might be a reference to a deleter functor that's destroyed during self-destruction.

We believed that 20.8.1.2.5 [unique.ptr.single.modifiers]/4 was already sufficiently clear. The Standard occasionally prevents implementations of X from doing various things, through the principle of "nothing allows X to fail in that situation". For example, v.push_back(v[0]) is required to work for non-empty vectors because nothing allows that to fail. In this case, the intent to allow self-destruction is already clear.

Additionally, we did not believe that 20.8.1.2.5 [unique.ptr.single.modifiers]/5 had to be changed. The current note is slightly squirrely but it does not lead to confusion for implementers or users.

Previous resolution from Rob Desbois:

  1. Edit 20.8.1.2 [unique.ptr.single] p1 as indicated:

    The default type for the template parameter D is default_delete. A client-supplied template argument D shall be a function object type (20.10), lvalue-reference to function, or lvalue-reference to function object type for which, given a value d of type D and a value ptr of type unique_ptr<T, D>::pointer, the expression d(ptr) is valid and has the effect of disposing of the pointer as appropriate for that deleter. Where D is not an lvalue reference type, d(ptr) shall be valid if ptr refers directly or indirectly to the invoking unique_ptr object.

  2. Edit 20.8.1.2.5 [unique.ptr.single.modifiers] p4+5 as indicated:

    void reset(pointer p = pointer()) noexcept;
    

    -3- Requires: The expression get_deleter()(get()) shall be well formed, shall have well-defined behavior, and shall not throw exceptions.

    -4- Effects: assigns p to the stored pointer, and then if the old value of the stored pointer, old_p, was not equal to nullptr, calls get_deleter()(old_p). No operation shall be performed after the call to get_deleter()(old_p) that requires *this to be valid, because the deletion may destroy *this if it is referred to directly or indirectly by the stored pointer. [Note: The order of these operations is significant because the call to get_deleter() may destroy *this. — end note]

    -5- Postconditions: If the call get_deleter()(old_p) destroyed *this, none. Otherwise, get() == p. [Note: The postcondition does not hold if the call to get_deleter() destroys *this since this->get() is no longer a valid expression. — end note]

Previous resolution [SUPERSEDED]:

This wording is relative to N3691.

  1. Edit 20.8.1.2 [unique.ptr.single] p1 as indicated:

    The default type for the template parameter D is default_delete. A client-supplied template argument D shall be a function object type (20.10), lvalue-reference to function, or lvalue-reference to function object type for which, given a value d of type D and a value ptr of type unique_ptr<T, D>::pointer, the expression d(ptr) is valid and has the effect of disposing of the pointer as appropriate for that deleter. d(ptr) shall be valid even if it triggers the destruction of d or (if D is an lvalue reference to function object type) the function object that d refers to.

[2015-05, Lenexa]

After some discussion in Lenexa there was some wavering on if the added sentence is necessary. Here is example code that demonstrates why the extra sentence is necessary. In this example the call to d(ptr) is valid, however the deleter references *this after destructing its element:

#include <cassert>
#include <memory>
#include <iostream>

class Deleter
{
    int state_ = 0;

    enum
    {
        destructed            = -4,
        self_move_assigned    = -3,
        move_assigned_from    = -2,
        move_constructed_from = -1
    };
public:
    ~Deleter() {state_ = destructed;}

    Deleter() = default;
    Deleter(Deleter const&) = default;
    Deleter& operator=(Deleter const&) = default;

    Deleter(Deleter&& a) noexcept
        : state_(a.state_)
    {a.state_ = move_constructed_from;}

    Deleter& operator=(Deleter&& a) noexcept
    {
        if (this == &a)
            state_ = self_move_assigned;
        else
        {
            state_ = a.state_;
            a.state_ = move_assigned_from;
        }
        return *this;
    }

    Deleter(int state)
        : state_(state)
    {
        assert(state >= 0);
    }

    template <class T>
    void
    operator()(T* t) const
    {
        std::cout << "Deleter beginning operator()(T*)\n";
        std::cout << "The deleter = " << *this << '\n';
        std::cout << "Deleter about to destruct the X.\n";
        delete t;
        std::cout << "Deleter has destructed the X.\n";
        std::cout << "The deleter = " << *this << '\n';
        std::cout << "Deleter ending operator()(T*)\n";
    }

    friend
    std::ostream&
    operator<<(std::ostream& os, const Deleter& a)
    {
        switch (a.state_)
        {
        case destructed:
            os << "**destructed**";
            break;
        case self_move_assigned:
            os << "self_move_assigned";
            break;
        case move_assigned_from:
            os << "move_assigned_from";
            break;
        case move_constructed_from:
            os << "move_constructed_from";
            break;
        default:
            os << a.state_;
            break;
        }
        return os;
    }
};

struct X
{
    Deleter deleter_{1};
};

int main()
{
    auto xp = new X;
    {
        std::unique_ptr<X, Deleter&> p(xp, xp->deleter_);
        std::cout << "unique_ptr is constructed.\n";
        std::cout << "The deleter = " << p.get_deleter() << '\n';
        std::cout << "Destructing unique_ptr...\n";
    }
    std::cout << "unique_ptr is destructed.\n";
}

Which outputs:

unique_ptr is constructed.
The deleter = 1
Destructing unique_ptr...
Deleter beginning operator()(T*)
The deleter = 1
Deleter about to destruct the X.
Deleter has destructed the X.
The deleter = **destructed**
Deleter ending operator()(T*)
unique_ptr is destructed.

The line "The deleter = **destructed**" represents the deleter referencing itself after it has been destructed by the d(ptr) expression, but prior to that call returning.

Suggested alternative to the current proposed wording:

The expression d(ptr) shall not refer to the object d after it executes ptr->~T().

Proposed resolution:

This wording is relative to N4431.

  1. Edit 20.8.1.2 [unique.ptr.single] p1 as indicated:

    The default type for the template parameter D is default_delete. A client-supplied template argument D shall be a function object type (20.9), lvalue-reference to function, or lvalue-reference to function object type for which, given a value d of type D and a value ptr of type unique_ptr<T, D>::pointer, the expression d(ptr) is valid and has the effect of disposing of the pointer as appropriate for that deleter. The expression d(ptr) shall not refer to the object d after it executes ptr->~T().


2264. [arrays.ts] std::dynarray defines its initializer-list constructor in terms of a non-existent constructor

Section: X [dynarray], 23.2 [container.requirements] Status: Open Submitter: Povilas Kanapickas Opened: 2013-05-22 Last modified: 2015-04-08

View all issues with Open status.

Discussion:

Addresses: arrays.ts

std::dynarray member listing at X [dynarray.overview] includes this constructor:

dynarray(initializer_list<T>);

Also, X [dynarray.overview] p. 2 says:

Unless otherwise specified, all dynarray operations have the same requirements and semantics as specified in 23.2.

The constructor in question isn't mentioned in X [dynarray.cons] or anywhere else. This means requirements from 23.2 [container.requirements] apply. However, Table 100 in 23.2.3 [sequence.reqmts] says:

X(il)               Equivalent to X(il.begin(), il.end())

std::dynarray does not provide this constructor.

The proposed resolution below adds the missing constructor and a complementary constructor with an allocator parameter. The new constructors, differently from the rest of containers, accept iterators that have forward iterator category. This is needed because the size requirements must be known in order to allocate appropriately-sized storage.

An alternative resolution could be to properly specify the initializer-list constructor.

[2013-09 Chicago:]

Move to Deferred. This feature will ship after C++14 and should be revisited then.

[2014-06-06 pre-Rapperswill]

This issue has been reopened as arrays-ts.

Proposed resolution:

  1. Add the following to the std::dynarray synopsis at X [dynarray.overview]:

    namespace std {
      template <class T>
      class dynarray {
        […]
        // 23.3.4.2 construct/copy/destroy:
        […]
        template <class ForwardIterator>
        dynarray(ForwardIterator first, ForwardIterator last);
        template <class ForwardIterator, class Alloc>
        dynarray(ForwardIterator first, ForwardIterator last, const Alloc& alloc);
        […]
      };
    }
    
  2. Add the following to X [dynarray.cons] after p. 8:

    template <class ForwardIterator>
    dynarray(ForwardIterator first, ForwardIterator last);
    

    -?- Requires: T shall meet the CopyConstructible requirements.

    -?- Effects: Allocates storage for distance(first, last) elements. The distance(first, last) elements of the dynarray are direct-initialized (8.5 [dcl.init]) with the corresponding elements from the range [first,last). May or may not invoke the global operator new.

    -?- Complexity: distance(first, last).

    -?- Throws: std::bad_array_length when the size requested is larger than implementable, std::bad_alloc when there is insufficient memory.

  3. Add the following to the list of constructors at X [dynarray.cons] before p. 9:

  4. template <class Alloc>
    dynarray(size_type c, const Alloc& alloc);
    template <class Alloc>
    dynarray(size_type c, const T& v, const Alloc& alloc);
    template <class Alloc>
    dynarray(const dynarray& d, const Alloc& alloc);
    template <class Alloc>
    dynarray(initializer_list<T>, const Alloc& alloc);
    template <class ForwardIterator, class Alloc>
    dynarray(ForwardIterator first, ForwardIterator last, const Alloc& alloc);
    

2265. 29.3p9 appears to rule out some acceptable executions

Section: 29.3 [atomics.order] Status: Open Submitter: Brian Demsky Opened: 2013-06-17 Last modified: 2015-05-08

View other active issues in [atomics.order].

View all other issues in [atomics.order].

View all issues with Open status.

Discussion:

I believe that the following variation on IRIW should admit executions in which c1 = d1 = 5 and c2 = d2 = 0. If this is allowed, then what is sequence of program evaluations for 29.3 [atomics.order] p9 that justifies the store to z? It seems that 29.3 [atomics.order] p9 should not allow this execution because one of the stores to x or y has to appear earlier in the sequence, each of the fetch_adds reads the previous load in the thread (and thus must appear later in the sequence), and 29.3 [atomics.order] p9 states that each load must read from the last prior assignment in the sequence.

atomic_int x;
atomic_int y;
atomic_int z;
int c1, c2, d1, d2;

static void a(void* obj)
{
  atomic_store_explicit(&x, 5, memory_order_relaxed); 
}

static void b(void* obj)
{
  atomic_store_explicit(&y, 5, memory_order_relaxed); 
}

static void c(void* obj)
{
  c1 = atomic_load_explicit(&x, memory_order_relaxed);
  // this could also be an atomic load if the address depends on c1:
  c2 = atomic_fetch_add_explicit(&y, c1, memory_order_relaxed);  
}

static void d(void* obj)
{
  d1 = atomic_load_explicit(&y, memory_order_relaxed);
  d2 = atomic_fetch_add_explicit(&x, d1, memory_order_relaxed); 
}

int user_main(int argc, char** argv)
{
  thrd_t t1, t2, t3, t4;

  atomic_init(&x, 0);
  atomic_init(&y, 0);

  printf("Main thread: creating 4 threads\n");
  thrd_create(&t1, (thrd_start_t)&a, NULL);
  thrd_create(&t2, (thrd_start_t)&b, NULL);
  thrd_create(&t3, (thrd_start_t)&c, NULL);
  thrd_create(&t4, (thrd_start_t)&d, NULL);

  thrd_join(t1);
  thrd_join(t2);
  thrd_join(t3);
  thrd_join(t4);
  printf("c1=%d c2=%d\n",c1,c2);
  printf("d1=%d d2=%d\n",d1,d2);

  // Can this store write 1000 (i.e., c1=d1=5, c2=d2=0)?
  atomic_store(&z, (c1+d1)*100+c2+d2);

  printf("Main thread is finished\n");

  return 0;
}

It seems that the easiest fix is to allow a load in 29.3 [atomics.order] p9 to read from any prior store in the evaluation order.

That said, I would personally advocate the following: It seems to me that C/C++ atomics are in a bit of different situation than Java because:

  1. People are expected to use relaxed C++ atomics in potentially racy situations, so it isn't clear that semantics as complicated as the JMM's causality would be sane.

  2. People who use C/C++ atomics are likely to be experts and use them in a very controlled fashion. I would be really surprised if compilers would find any real wins by optimizing the use of atomics.

Why not do something like:

There is satisfaction DAG of all program evaluations. Each evaluation observes the values of variables as computed by some prior assignment in the DAG.

There is an edge x->y between two evaluations x and y if:

  1. the evaluation y observes a value computed by the evaluation x or

  2. the evaluation y is an atomic store, the evaluation x is an atomic load, and there is a condition branch c that may depend (intrathread dependence) on x and x-sb->c and c-sb->y.

This seems to allow reordering of relaxed atomics that processors do without extra fence instructions, allows most reorderings by the compiler, and gets rid of satisfaction cycles.

[2015-02 Cologne]

Handed over to SG1.

[2015-05 Lenexa, SG1 response]

This was partially addressed (weasel-worded) in C++14 (See N3786). The remainder is an open research problem. N3710 outlines a "solution" that doesn't have a consensus behind it because it costs performance. We have no better solution at the moment.

Proposed resolution:


2267. partial_sort_copy underspecified for ranges of two different types

Section: 25.4.1.4 [partial.sort.copy] Status: New Submitter: Matt Austern Opened: 2013-06-26 Last modified: 2015-04-08

View all issues with New status.

Discussion:

The signature of this function is:

template<class InputIterator, class RandomAccessIterator>
RandomAccessIterator
partial_sort_copy(InputIterator first, InputIterator last,
                  RandomAccessIterator result_first,
                  RandomAccessIterator result_last);

(and the usual overload for an explicitly provided comparison function). The standard says nothing about requirements in the case where the input type (iterator_traits<InputIterator>::value_type) and the output type (iterator_traits<RandomAccessIterator>::value_type) are different.

Presumably the input type must be convertible to the output type. What's less clear is what the requirements are on the comparison operator. Does the algorithm only perform comparisons on two values of the output type, or does it also perform comparisons on values of the input type, or might it even perform heterogeneous comparisons?

Proposed resolution:


2269. Container iterators and argument-dependent lookup

Section: 23.2.1 [container.requirements.general] Status: New Submitter: Matt Austern Opened: 2013-06-26 Last modified: 2015-04-08

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

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

View all issues with New status.

Discussion:

Consider the following code snippet:

#include <vector>
#include <algorithm>

int main() {
  std::vector<int> v1(100, 3);
  std::vector<int> v2(100);
  copy(v1.begin(), v1.end(), v2.begin());
}

It compiles without error on my desktop. Is it required to? I can't find evidence from the standard that it is. In my test std::copy was found by argument-dependent lookup because the implementation I used made std::vector<int>::iterator a user-defined type defined in namespace std. But the standard only requires std::vector<int>::iterator to be an implementation specified random access iterator type. I can't find anything requiring it to be a user-defined type at all (and in fact there are reasonable implementation where it isn't), let alone a user defined type defined in a specific namespace.

Since the defining namespace of container iterators is visible to users, should the standard say anything about what that namespace is?

Proposed resolution:


2273. regex_match ambiguity

Section: 28.11.2 [re.alg.match] Status: Open Submitter: Howard Hinnant Opened: 2013-07-14 Last modified: 2015-04-08

View all other issues in [re.alg.match].

View all issues with Open status.

Discussion:

28.11.2 [re.alg.match] p2 in describing regex_match says:

-2- Effects: Determines whether there is a match between the regular expression e, and all of the character sequence [first,last). The parameter flags is used to control how the expression is matched against the character sequence. Returns true if such a match exists, false otherwise.

It has come to my attention that different people are interpreting the first sentence of p2 in different ways:

  1. If a search of the input string using the regular expression e matches the entire input string, regex_match should return true.

  2. Search the input string using the regular expression e. Reject all matches that do not match the entire input string. If a such a match is found, return true.

The difference between these two subtly different interpretations is found using the following ECMAScript example:

std::regex re("Get|GetValue");

Using regex_search, this re can never match the input string "GetValue", because ECMA specifies that alternations are ordered, not greedy. As soon as "Get" is matched in the left alternation, the matching algorithm stops.

Using definition 1, regex_match would return false for an input string of "GetValue".

However definition 2 alters the grammar and appears equivalent to augmenting the regex with a trailing '$', which is an anchor that specifies, reject any matches which do not come at the end of the input sequence. So, using definition 2, regex_match would return true for an input string of "GetValue".

My opinion is that it would be strange to have regex_match return true for a string/regex pair that regex_search could never find. I.e. I favor definition 1.

John Maddock writes:

The intention was always that regex_match would reject any match candidate which didn't match the entire input string. So it would find GetValue in this case because the "Get" alternative had already been rejected as not matching. Note that the comparison with ECMA script is somewhat moot, as ECMAScript defines the regex grammar (the bit we've imported), it does not define anything like regex_match, nor do we import from ECMAScript the behaviour of that function. So IMO the function should behave consistently regardless of the regex dialect chosen. Saying "use awk regexes" doesn't cut it, because that changes the grammar in other ways.

(John favors definition 2).

We need to clarify 28.11.2 [re.alg.match]/p2 in one of these two directions.

[2014-06-21, Rapperswil]

AM: I think there's a clear direction and consensus we agree with John Maddock's position, and if noone else thinks we need the other function I won't ask for it.

Marshall Clow and STL to draft.

Proposed resolution:


2276. Missing requirement on std::promise::set_exception

Section: 30.6 [futures] Status: Open Submitter: Jonathan Wakely Opened: 2013-07-30 Last modified: 2015-05-08

View all other issues in [futures].

View all issues with Open status.

Discussion:

The standard does not specify the behaviour of this program:

#include <future>
#include <cassert>

struct NonTrivial
{
  NonTrivial() : init(true) { }
  ~NonTrivial() { assert(init); }
  bool init;
};

int main()
{
  std::promise<NonTrivial> p;
  auto f = p.get_future();
  p.set_exception(std::exception_ptr());
  f.get();
}

The standard doesn't forbid making the state ready with a null exception_ptr, so what should get() return? There's no stored exception to throw, but it can't return a value because none was initialized.

A careful reading of the standard shows 30.6.4 [futures.state] p8 says "A shared state is ready only if it holds a value or an exception ready for retrieval." One can infer from the fact that set_exception() makes the state ready that it must store a value or exception, so cannot store "nothing", but that isn't explicit.

The promise::set_exception() and promise::set_exception_at_thread_exit() members should require p != nullptr or should state the type of exception thrown if p is null.

[2015-02 Cologne]

Handed over to SG1.

[2015-05 Lenexa, SG1 response]

SG1 provides P/R and requests move to SG1-OK status: Add Requires clauses for promise (30.6.5 [futures.promise]) set_exception (before p18) and set_exception_at_thread_exit (before p24): Requires: p is not null.

Proposed resolution:

This wording is relative to N4431.

Add Requires clauses for promise (30.6.5 [futures.promise]) set_exception (before p18) and set_exception_at_thread_exit (before p24): Requires: p is not null.
  1. Change 30.6.5 [futures.promise] as depicted:

    void set_exception(exception_ptr p);
    

    -??- Requires: p is not null.

    -18- Effects: atomically stores the exception pointer p in the shared state and makes that state ready (30.6.4).

    void set_exception_at_thread_exit(exception_ptr p);
    

    -??- Requires: p is not null.

    -24- Effects: Stores the exception pointer p in the shared state without making that state ready immediately. […]


2277. [arrays.ts] <dynarray> is missing in 24.7/1

Section: 24.7 [iterator.range] Status: Open Submitter: Cassio Neri Opened: 2013-07-31 Last modified: 2015-04-08

View other active issues in [iterator.range].

View all other issues in [iterator.range].

View all issues with Open status.

Discussion:

Addresses: arrays.ts

Section 24.7 [iterator.range] p1 specifies header files that, in addition to <iterator>, make available the function templates in 24.7 (begin, end, etc.) but it fails to mention <dynarray>. This seems to be just an oversight.

[2013-09 Chicago:]

Move to Deferred. This feature will ship after C++14 and should be revisited then.

[2014-06-06 pre-Rapperswill]

This issue has been reopened as arrays-ts.

Proposed resolution:

This wording is relative to N3691.

  1. Modify 24.7 [iterator.range] p1 as indicated:

    -1- In addition to being available via inclusion of the <iterator> header, the function templates in 24.7 are available when any of the following headers are included: <array>, <deque>, <dynarray>, <forward_list>, <list>, <map>, <regex>, <set>, <string>, <unordered_map>, <unordered_set>, and <vector>.


2286. stringbuf::underflow() underspecified

Section: 27.8.2.4 [stringbuf.virtuals] Status: New Submitter: Sergey Zubkov Opened: 2013-08-29 Last modified: 2015-04-08

View all other issues in [stringbuf.virtuals].

View all issues with New status.

Discussion:

In 27.8.2.4 [stringbuf.virtuals]/1, basic_stringbuf::underflow() is specified to unconditionally return traits::eof() when a read position is not available.

The semantics of basic_stringbuf require, and existing libraries implement it so that this function makes a read position available if possible to do so, e.g. if some characters were inserted into the stream since the last call to overflow(), resulting in pptr() > egptr(). Compare to the conceptually similar D.7.1.3 [depr.strstreambuf.virtuals]/15.

Proposed resolution:

This wording is relative to N3691.

  1. Change 27.8.2.4 [stringbuf.virtuals] as indicated:

    int_type underflow();
    

    -1- Returns: If the input sequence has a read position available or the function makes a read position available (as described below), returns traits::to_int_type(*gptr()). Otherwise, returns traits::eof(). Any character in the underlying buffer which has been initialized is considered to be part of the input sequence.

    -?- The function can make a read position available only if (mode & ios_base::in) != 0 and if the write next pointer pptr() is not null and is greater than the current read end pointer egptr(). To make a read position available, the function alters the read end pointer egptr() to equal pptr().


2289. constexpr guarantees of defaulted functions still insufficient

Section: 20.3.2 [pairs.pair], 20.4.2.1 [tuple.cnstr], 20.12.5 [time.duration] Status: Open Submitter: Daniel Krügler Opened: 2013-09-09 Last modified: 2015-05-22

View all other issues in [pairs.pair].

View all issues with Open status.

Discussion:

During the acceptance of N3471 and some similar constexpr papers, specific wording was added to pair, tuple, and other templates that were intended to impose implementation constraints that ensure that the observable constexpr "character" of a defaulted function template is solely determined by the required expressions of the user-provided types when instantiated, for example:

The defaulted move and copy constructor, respectively, of pair shall be a constexpr function if and only if all required element-wise initializations for copy and move, respectively, would satisfy the requirements for a constexpr function.

This wording doesn't require enough, especially since the core language via CWG 1358 does now support constexpr function template instantiations, even if such function cannot appear in a constant expression (as specified in 5.20 [expr.const]) or as a constant initializer of that object (as specified in 3.6.2 [basic.start.init]). The wording should be improved and should require valid uses in constant expressions and as constant initializers instead.

[Lenexa 2015-05-05]

STL : notice order of move/copy and copy/move with "respectively".

General word-smithing; ask for updated wording

Are we happy with this with changes we are suggesting?

unanimous

Proposed resolution:

This wording is relative to N3691.

  1. Change 20.3.2 [pairs.pair] p2 as indicated:

    -2- The defaulted move and copy constructor, respectively, of pair shall be a constexpr function if and only if all required element-wise initializations for copy and move, respectively, would satisfy the requirements for a constexpr functionAn invocation of the move or copy constructor of pair shall be a constant expression (5.20 [expr.const]) if all required element-wise initializations would be constant expressions. An invocation of the move or copy constructor of pair shall be a constant initializer for that pair object (3.6.2 [basic.start.init]) if all required element-wise initializations would be constant initializers for the respective subobjects.

  2. Change 20.4.2.1 [tuple.cnstr] p2 as indicated:

    -2- The defaulted move and copy constructor, respectively, of tuple shall be a constexpr function if and only if all required element-wise initializations for copy and move, respectively, would satisfy the requirements for a constexpr function. The defaulted move and copy constructor of tuple<> shall be constexpr functionsAn invocation of the move or copy constructor of tuple shall be a constant expression (5.20 [expr.const]) if all required element-wise initializations would be constant expressions. An invocation of the move or copy constructor of tuple shall be a constant initializer for that tuple object (3.6.2 [basic.start.init]) if all required element-wise initializations would be constant initializers for the respective subobjects. An invocation of the move or copy constructor of tuple<> shall be a constant expression, or a constant initializer for that tuple<> object, respectively, if the function argument would be constant expression.

  3. Change 20.12.5 [time.duration] p7 as indicated:

    -7- Remarks: The defaulted copy constructor of duration shall be a constexpr function if and only if the required initialization of the member rep_ for copy and move, respectively, would satisfy the requirements for a constexpr function.An invocation of the copy constructor of duration shall be a constant expression (5.20 [expr.const]) if the required initialization of the member rep_ would be a constant expression. An invocation of the copy constructor of duration shall be a constant initializer for that duration object (3.6.2 [basic.start.init]) if the required initialization of the member rep_ would be constant initializers for this subobject.


2290. Top-level "SFINAE"-based constraints should get a separate definition in Clause 17

Section: 20.10 [meta] Status: New Submitter: Daniel Krügler Opened: 2013-09-02 Last modified: 2015-05-22

View other active issues in [meta].

View all other issues in [meta].

View all issues with New status.

Discussion:

The current library specification uses at several places wording that is intended to refer to core language template deduction failure at the top-level of expressions (aka "SFINAE"), for example:

The expression declval<T>() = declval<U>() is well-formed when treated as an unevaluated operand (Clause 5). Access checking is performed as if in a context unrelated to T and U. Only the validity of the immediate context of the assignment expression is considered. [Note: The compilation of the expression can result in side effects such as the instantiation of class template specializations and function template specializations, the generation of implicitly-defined functions, and so on. Such side effects are not in the "immediate context" and can result in the program being ill-formed. — end note]

Similar wording can be found in the specification of result_of, is_constructible, and is_convertible, being added to resolve an NB comment by LWG 1390 and 1391 through N3142.

This wording is necessary to limit speculative compilations needed to implement these traits, but it is also lengthy and repetitive.

[2014-05-19, Daniel suggests a descriptive term]

constrictedly well-formed expression:

An expression e depending on a set of types A1, ..., An which is well-formed when treated as an unevaluated operand (Clause 5). Access checking is performed as if in a context unrelated to A1, ..., An. Only the validity of the immediate context of e is considered. [Note: The compilation of the expression can result in side effects such as the instantiation of class template specializations and function template specializations, the generation of implicitly-defined functions, and so on. Such side effects are not in the "immediate context" and can result in the program being ill-formed. — end note]

[2014-05-20, Richard and Jonathan suggest better terms]

Richard suggested "locally well-formed"

Jonathan suggested "contextually well-formed" and then "The expression ... is valid in a contrived argument deduction context"

[2014-06-07, Daniel comments and improves wording]

The 2014-05-19 suggestion did only apply to expressions, but there are two important examples that are not expressions, but instead are involving an object definition (std::is_constructible) and a function definition (std::is_convertible), respectively, instead. Therefore I suggest to rephrase the usage of "expression" into "program construct" in the definition of Jonathan's suggestion of "valid in a contrived argument deduction context".

I would like to point out that given the new definition of "valid in a contrived argument deduction context", there are several other places of the Library specification that could take advantage of this wording to improve the existing specification, such as 20.9.12.2 [func.wrap.func] p2, most functions in 20.7.8.2 [allocator.traits.members], and the **Insertable, EmplaceConstructible, and Erasable definitions in 23.2.1 [container.requirements.general], but given that these are not fully described in terms of the aforementioned wording yet, I would recommend to fix them by a separate issue once the committee has agreed on following the suggestion presented by this issue.

[2015-05-05 Lenexa: Move to Open]

...

MC: I think we like the direction but it isn't quite right: it needs some work

JW: I'm prepared to volunteer to move that further, hopefully with the help of Daniel

Roger Orr: should this be Core wording because it doesn't really have anything to do with libraries - the term could then just be used here

AM: Core has nothing to deal with that, though

HT: it seems there is nothing to imply that allows dropping out with an error - maybe that's a separate issue

MC: I'm not getting what you are getting at: could you write an issue? - any objection to move to Open?

...

Proposed resolution:

This wording is relative to N3936.

  1. Add the following new definition to 17.3 [definitions] as indicated:

    valid in a contrived argument deduction context [defns.valid.contr.context]

    A program construct c depending on a set of types A1, ..., An, and treated as an unevaluated operand (Clause 5) when c is an expression, which is well-formed. Access checking is performed as if in a context unrelated to A1, ..., An. Only the validity of the immediate context (14.8.2 [temp.deduct]) of c is considered. [Note: The compilation of c can result in side effects such as the instantiation of class template specializations and function template specializations, the generation of implicitly-defined functions, and so on. Such side effects are not in the "immediate context" and can result in the program being ill-formed. — end note].

  2. Change Table 49 ("Type property predicates") as indicated:

    Table 49 — Type property predicates
    Template Condition Preconditions
    template <class T, class U>
    struct is_assignable;
    The expression declval<T>() =
    declval<U>()
    is valid in a
    contrived argument deduction context
    ([defns.valid.contr.context]) for types
    T and U.
    well-formed when treated
    as an unevaluated operand
    (Clause 5). Access
    checking is performed as if
    in a context unrelated to T
    and U. Only the validity of
    the immediate context of
    the assignment expression
    is considered. [Note: The
    compilation of the
    expression can result in
    side effects such as the
    instantiation of class
    template specializations
    and function template
    specializations, the
    generation of
    implicitly-defined
    functions, and so on. Such
    side effects are not in the
    "immediate context" and
    can result in the program
    being ill-formed. — end
    note]
    […]
  3. Change 20.10.4.3 [meta.unary.prop] p7 as indicated:

    -7- Given the following function prototype:

    template <class T>
      add_rvalue_reference_t<T> create() noexcept;
    

    the predicate condition for a template specialization is_constructible<T, Args...> shall be satisfied if and only if the following variable definition would be well-formed for some invented variable t would be valid in a contrived argument deduction context ([defns.valid.contr.context]) for types T and Args...:

    T t(create<Args>()...);
    

    [Note: These tokens are never interpreted as a function declaration. — end note] Access checking is performed as if in a context unrelated to T and any of the Args. Only the validity of the immediate context of the variable initialization is considered. [Note: The evaluation of the initialization can result in side effects such as the instantiation of class template specializations and function template specializations, the generation of implicitly-defined functions, and so on. Such side effects are not in the "immediate context" and can result in the program being ill-formed. — end note]

  4. Change Table 57 ("Other transformations") as indicated:

    Table 57 — Other transformations
    Template Condition Comments
    template <class Fn, class... ArgTypes>
    struct result_of<Fn(ArgTypes...)>;
    […] If the expression
    INVOKE(declval<Fn>(),
    declval<ArgTypes>()...)
    is
    valid in a contrived argument deduction
    context ([defns.valid.contr.context]) for types
    Fn and ArgTypes...
    well
    formed when treated as an
    unevaluated operand (Clause 5)
    , the
    member typedef type shall name the
    type
    decltype(INVOKE(declval<Fn>(),
    declval<ArgTypes>()...))
    ;
    otherwise, there shall be no member
    type. Access checking is performed as
    if in a context unrelated to Fn and
    ArgTypes. Only the validity of the
    immediate context of the expression is
    considered. [Note: The compilation of
    the expression can result in side
    effects such as the instantiation of
    class template specializations and
    function template specializations, the
    generation of implicitly-defined
    functions, and so on. Such side effects
    are not in the "immediate context"
    and can result in the program being
    ill-formed. — end note]
  5. Change 20.10.6 [meta.rel] p4 as indicated:

    -4- Given the following function prototype:

    template <class T>
      add_rvalue_reference_t<T> create() noexcept;
    

    the predicate condition for a template specialization is_convertible<From, To> shall be satisfied if and only if the return expression in the following code would be well-formedvalid in a contrived argument deduction context ([defns.valid.contr.context]) for types To and From, including any implicit conversions to the return type of the function:

    To test() {
      return create<From>();
    }
    

    [Note: This requirement gives well defined results for reference types, void types, array types, and function types. — end note] Access checking is performed as if in a context unrelated to To and From. Only the validity of the immediate context of the expression of the return-statement (including conversions to the return type) is considered. [Note: The evaluation of the conversion can result in side effects such as the instantiation of class template specializations and function template specializations, the generation of implicitly-defined functions, and so on. Such side effects are not in the "immediate context" and can result in the program being ill-formed. — end note]


2292. Find a better phrasing for "shall not participate in overload resolution"

Section: 17.5.1.4 [structure.specifications] Status: New Submitter: Jeffrey Yasskin Opened: 2013-09-03 Last modified: 2015-04-08

View all other issues in [structure.specifications].

View all issues with New status.

Discussion:

The C++14 CD has 25 sections including the phrase "X shall not participate in overload resolution ...". Most of these uses are double negatives, which are hard to interpret. "shall not ... unless" tends to be the easiest to read, since the condition is true when the function is available, but we also have a lot of "if X is not Y, then Z shall not participate", which actually means "You can call Z if X is Y." The current wording is also clumsy and long-winded. We should find a better and more concise phrasing.

As an initial proposal, I'd suggest using "X is enabled if and only if Y" in prose and adding an "Enabled If: ..." element to 17.5.1.4 [structure.specifications].

Daniel:

I suggest to name this new specification element for 17.5.1.4 [structure.specifications] as "Template Constraints:" instead, because the mentioned wording form was intentionally provided starting with LWG 1237 to give implementations more freedom to realize the concrete constraints. Instead of the original std::enable_if-based specifications we can use better forms of "SFINAE" constraints today and it eases the path to possible language-based constraints in the future.

Proposed resolution:


2294. <cstdlib> should declare abs(double)

Section: 26.8 [c.math] Status: Open Submitter: Pete Becker Opened: 2013-09-04 Last modified: 2015-04-08

View other active issues in [c.math].

View all other issues in [c.math].

View all issues with Open status.

Discussion:

… and abs(float) and abs(long double). And <cmath> should declare abs(int), abs(long), and abs(long long).

As things currently stand, this program is illegal:

#include <cstdlib>

int main() {
  double d = -1.23;
  double dd = std::abs(d);
  return 0;
}

The call is ambiguous because of the various integer overloads, that's because <cstdlib> provides abs(int) but not abs(double).

This lead one commenter on Stackoverflow to state that abs is dangerous, and to recommend using fabs instead.

In general, it makes sense to declare overloaded functions that take user-defined types in the same header as the definition of the user-defined types; it isn't necessary to declare all of the overloads in the same place. But here we're not dealing with any user-defined types; we're dealing with builtin types, which are always defined; all of the overloads should be defined in the same place, to avoid mysterious problems like the one in the code above.

The standard library has six overloads for abs:

int abs(int);  // <cstdlib>
long abs(long); // <cstdlib>
long long abs(long long); // <cstdlib>

float abs(float); // <cmath>
double abs(double); // <cmath>
long double abs(long double); // <cmath>

These should all be declared in both headers.

I have no opinion on <stdlib.h> and <math.h>.

[2013-09 Chicago]

This issue is related to LWG 2192

Move to open

[2014-02-13 Issaquah — Nicolai Josuttis suggest wording]

[2015-03-03, Geoffrey Romer provides improved wording]

See proposed resolution of LWG 2192.

Previous resolution from Nicolai [SUPERSEDED]:
  1. Edit 26.8 [c.math] after p7 as indicated:

    -6- In addition to the int versions of certain math functions in <cstdlib>, C++ adds long and long long overloaded versions of these functions, with the same semantics.

    -7- The added signatures are:

    long abs(long);                    // labs()
    long long abs(long long);          // llabs()
    ldiv_t div(long, long);            // ldiv()
    lldiv_t div(long long, long long); // lldiv()
    

    -?- To avoid ambiguities, C++ also adds the following overloads of abs() to <cstdlib>, with the semantics defined in <cmath>:

    float abs(float);
    double abs(double);
    long double abs(long double);
    

    -?- To avoid ambiguities, C++ also adds the following overloads of abs() to <cmath>, with the semantics defined in <cstdlib>:

    int abs(int);
    long abs(long);
    long long abs(long long);
    

Proposed resolution:

See proposed resolution of LWG 2192.


2295. Locale name when the provided Facet is a nullptr

Section: 22.3.1.2 [locale.cons] Status: New Submitter: Juan Soulie Opened: 2013-09-04 Last modified: 2015-04-08

View all issues with New status.

Discussion:

22.3.1.2 [locale.cons] p14 ends with:

"[…] If f is null, the resulting object is a copy of other."

but the next line p15 says:

"Remarks: The resulting locale has no name."

But both can't be true when other has a name and f is null.

I've tried it on two implementations (MSVC,GCC) and they are inconsistent with each other on this.

Daniel Krügler:

As currently written, the Remarks element applies unconditionally for all cases and thus should "win". The question arises whether the introduction of this element by LWG 424 had actually intended to change the previous Note to a Remarks element. In either case the wording should be improved to clarify this special case.

Proposed resolution:


2296. std::addressof should be constexpr

Section: 20.7.12.1 [specialized.addressof] Status: Review Submitter: Daryle Walker Opened: 2013-09-08 Last modified: 2015-05-08

View all other issues in [specialized.addressof].

View all issues with Review status.

Discussion:

I'm writing a function that needs to be constexpr and I wanted to take the address of its input. I was thinking of using std::addressof to be safe, but it isn't currently constexpr. A sample implementation couldn't be constexpr under the C++11 rules, though.

Daniel Krügler:

Indeed the core language clarified by CWG 1312 and by CWG 1384, that such emulations of std::addressof implementations are not valid in constant expressions, therefore it seems more like a defect than a feature request to ask for the guarantee that std::addressof is a constexpr function. It should be added that a similar requirement already exists for offsetof indirectly via the C99 standard as of 7.17 p3:

The macros are […]

offsetof(type, member-designator)

which expands to an integer constant expression that has type size_t […]

combined with the noted property in C++11 that:

"offsetof is required to work as specified even if unary operator& is overloaded for any of the types involved"

Therefore implementations should already be able without heroic efforts to realize this functionality by some intrinsic. The wording needs at least to ensure that for any lvalue core constant expression e the expression std::addressof(e) is a core constant expression.

[2013-09 Chicago]

[2014-06-08, Daniel improves wording]

It has been ensured that the wording is in sync with the recent working paper and the usage of "any" has been improved to say "every" instead (the fix is similar to that applied by LWG 2150).

Previous resolution from Daniel [SUPERSEDED]:

  1. Change header <memory> synopsis, 20.7.2 [memory.syn] as indicated:

    namespace std {
      […]
      // 20.7.12 [specialized.algorithms], specialized algorithms:
      template <class T> constexpr T* addressof(T& r) noexcept;
      […]
    }
    
  2. Change 20.7.12.1 [specialized.addressof] as indicated:

    template <class T> constexpr T* addressof(T& r) noexcept;
    

    -1- Returns: The actual address of the object or function referenced by r, even in the presence of an overloaded operator&.

    -?- Remarks: For every lvalue core constant expression e (5.20 [expr.const]), the expression std::addressof(e) is a core constant expression.

[2014-06-09, further improvements]

A new wording form is now used similar to the approach used by LWG 2234, which is a stricter way to impose the necessary implementation requirements.

[2015-05, Lenexa]

STL: the intent of this change is good; I think the wording is good
- I'm a bit worried about asking for a compiler hook
- if every implementer says: yes they can do it we should be good
EB: there is missing the word "a" before "subexpression" (in multiple places)
MC: the editor should do - we rely on our editors
MC: move to Review with a note stating that we wait for implementation experience first
- in favor: 13, opposed: 0, abstain: 2 HB: N4430 will bring something which is addressing this issue
MC: good we didn't go to ready then

Proposed resolution:

This wording is relative to N3936.

  1. Introduce the following new definition to the existing list in 17.3 [definitions]: [Drafting note: If LWG 2234 is accepted before this issue, the accepted wording for the new definition should be used instead — end drafting note]

    constant subexpression [defns.const.subexpr]

    an expression whose evaluation as subexpression of a conditional-expression CE (5.16 [expr.cond]) would not prevent CE from being a core constant expression (5.20 [expr.const]).

  2. Change header <memory> synopsis, 20.7.2 [memory.syn] as indicated:

    namespace std {
      […]
      // 20.7.12 [specialized.algorithms], specialized algorithms:
      template <class T> constexpr T* addressof(T& r) noexcept;
      […]
    }
    
  3. Change 20.7.12.1 [specialized.addressof] as indicated:

    template <class T> constexpr T* addressof(T& r) noexcept;
    

    -1- Returns: The actual address of the object or function referenced by r, even in the presence of an overloaded operator&.

    -?- Remarks: An expression std::addressof(E) is a constant subexpression ( [defns.const.subexpr]), if E is an lvalue constant subexpression.


2303. Explicit instantiation of std::vector<UserType> broken?

Section: 18.6.1.3 [new.delete.placement] Status: New Submitter: Daniel Krügler Opened: 2013-09-18 Last modified: 2015-04-08

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

View all issues with New status.

Discussion:

The library gives explicit permission in 17.6.4.2.1 [namespace.std] p2 that user code may explicitly instantiate a library template provided that the instantiations depend on at least one user-defined type:

A program may explicitly instantiate a template defined in the standard library only if the declaration depends on the name of a user-defined type and the instantiation meets the standard library requirements for the original template.

But it seems that the C++11 library is not specified in a way that guarantees such an instantiation to be well-formed if the minimum requirements of the library is not satisfied.

For example, in general, the first template parameter of std::vector is not required to be DefaultConstructible in general, but due to the split of the single C++03 member function with default argument

void resize(size_type sz, T c = T());

into

void resize(size_type sz);
void resize(size_type sz, const T& c);

the effect is now that for a type ND that is not DefaultConstructible, such as

struct NP { 
  NP(int); 
};

the explicit instantiation of std::vector<ND> is no longer well-formed, because the attempt to instantiate the single-argument overload of resize cannot not succeed, because this function imposes the DefaultInsertable requirements and given the default allocator this effectively requires DefaultConstructible.

But DefaultConstructible is not the only point, what about CopyConstructible versus MoveConstructible alone? It turns out that currently the second resize overload would fail during an explicit instantiation for a type like

struct MO { 
  MO() = default; 
  MO(MO&&) = default; 
};

because it imposes CopyInsertable requirements that end up being equivalent to the CopyConstructible requirements for the default allocator.

Technically a library can solve these issues: For special member functions by defining them in some base class, for others by transforming them effectively into a function template due to the great feature of default template arguments for function templates (At the very moment the validity of the latter approach depends on a resolution of core language issue CWG 1635, though). E.g. the here mentioned resize functions of std::vector could be prevented from instantiation by defining them like this with an implementation:

template<class = void>
void resize(size_type sz) { […] }
template<class = void>
void resize(size_type sz, const T& c) { […] }

In this case, these functions could also be defined in a base class, but the latter approach won't work in all cases.

Basically such an implementation is required to constrain all member functions that are not covered by the general requirements imposed on the actual library template parameters. I tested three different C++11 library implementations and but none could instantiate for example std::list, std::vector, or std::deque with value types that are not DefaultConstructible or only MoveConstructible.

This issue is raised to clarify the current situation in regard to the actual requirements imposed on user-provided types that are used to explicitly instantiate Library-provided templates. For example, the current Container requirements impose very little requirements on the actual value type and it is unclear to which extend library implementations have to respect that.

The minimum solution of this issue should be to at least realize that there is no fundamental requirement on DefaultConstructible for value types of library containers, because we have since C++03 the general statement of 17.6.3.1 [utility.arg.requirements] ("In general, a default constructor is not required."). It is unclear whether CopyConstructible should be required for an explicit instantiation request, but given the careful introduction of move operations in the library it would seem astonishing that a MoveConstructible type wouldn't suffice for value types of the container types.

In any case I can envision at least two approaches to solve this issue:

  1. As indicated in LWG 2292, those function could get an explicit "Template Constraints:" element, albeit this promises more than needed to solve this issue.

  2. The library could introduce a completely new element form, such as "Instantiation Constraints:" that would handle this situation for explicit instantiation situations. This would allow for simpler techniques to solve the issue when explicit instantiation is required compared to the first bullet, because it would not (necessarily) guarantee SFINAE-friendly expression-wellformedness, such as inspecting the expression std::declval<std::vector<ND>&>.resize(0) in an unevaluated context.

It should be noted that the 2013-08-27 comment to LWG 2193 could be resolved by a similar solution as indicated in this issue here.

Proposed resolution:


2307. Should the Standard Library use explicit only when necessary?

Section: 23 [containers] Status: Open Submitter: Zhihao Yuan Opened: 2013-09-26 Last modified: 2015-04-08

View other active issues in [containers].

View all other issues in [containers].

View all issues with Open status.

Discussion:

LWG 2193 yields explicit for default ctors to allow {}, but not for all cases of uniform initialization. For example:

explicit vector(size_type count, const Allocator& alloc = Allocator());

This prevents {n, alloc()}. Although this use is relatively rare, but the behavior is inconsistent with that of

vector(size_type count, const T& value, const Allocator& alloc = Allocator());

[Urbana 2014-11-07: Move to Open]

Proposed resolution:


2309. mutex::lock() should not throw device_or_resource_busy

Section: 30.4.1.2 [thread.mutex.requirements.mutex] Status: Open Submitter: Detlef Vollmann Opened: 2013-09-27 Last modified: 2015-05-08

View all other issues in [thread.mutex.requirements.mutex].

View all issues with Open status.

Discussion:

As discussed during the Chicago meeting in SG1 the only reasonable reasons for throwing device_or_resource_busy seem to be:

[2014-06-17 Rapperswil]

Detlef provides wording

[2015-02 Cologne]

Handed over to SG1.

[2015-05 Lenexa, SG1 response]

We believe we were already done with it. Should be in SG1-OK status.

Proposed resolution:

This wording is relative to N3936.

  1. Change 30.4.1.2 [thread.mutex.requirements.mutex] as indicated:

    -13- Error conditions:

    • operation_not_permitted — if the thread does not have the privilege to perform the operation.

    • resource_deadlock_would_occur — if the implementation detects that a deadlock would occur.

    • device_or_resource_busy — if the mutex is already locked and blocking is not possible.


2310. Public exposition only member in std::array

Section: 23.3.2.1 [array.overview] Status: Open Submitter: Jonathan Wakely Opened: 2013-09-30 Last modified: 2015-04-08

View all issues with Open status.

Discussion:

23.3.2.1 [array.overview] shows std::array with an "exposition only" data member, elems.

The wording in 17.5.2.3 [objects.within.classes] that defines how "exposition only" is used says it applies to private members, but std::array::elems (or its equivalent) must be public in order for std::array to be an aggregate.

If the intention is that std::array::elems places requirements on the implementation to provide "equivalent external behavior" to a public array member, then 17.5.2.3 [objects.within.classes] needs to cover public members too, or some other form should be used in 23.3.2.1 [array.overview].

[Urbana 2014-11-07: Move to Open]

Proposed resolution:


2312. tuple's constructor constraints need to be phrased more precisely

Section: 20.4.2.1 [tuple.cnstr] Status: Open Submitter: Stephan T. Lavavej Opened: 2013-09-21 Last modified: 2015-05-06

View other active issues in [tuple.cnstr].

View all other issues in [tuple.cnstr].

View all issues with Open status.

Discussion:

Consider the following code:

void meow(tuple<long, long>) { puts("Two"); }

void meow(tuple<long, long, long>) { puts("Three"); }

tuple<int, int, int> t(0, 0, 0);

meow(t);

This should compile and print "Three" because tuple<long, long>'s constructor from const tuple<int, int, int>& should remove itself from overload resolution. Implementations sensibly do this, but the Standard doesn't actually say it!

In this case, Types is "long, long" and UTypes is "int, int, int". 20.4.2.1 [tuple.cnstr]/3 says "let i be in the range [0,sizeof...(Types)) in order", which is [0, 2). Then /17 says "Remark: This constructor shall not participate in overload resolution unless const Ui& is implicitly convertible to Ti for all i." Interpreted literally, this is true! /15 says "Requires: sizeof...(Types) == sizeof...(UTypes)." but requiring the sizes to be identical doesn't help. Only the special phrase "shall not participate in overload resolution unless" mandates SFINAE/enable_if machinery.

The wording that we need is almost available in the Requires paragraphs, except that the Requires paragraphs say "is_constructible" while the Remark paragraphs say "is implicitly convertible", which is the correct thing for the SFINAE constraints to check. My proposed resolution is to unify the Requires and Remark paragraphs, after which there will be no need for Requires (when a constructor participates in overload resolution if and only if X is true, then there's no need for it to Require that X is true).

Note: 20.10.4.3 [meta.unary.prop]/6 specifies is_constructible<To, From> and 20.10.6 [meta.rel]/4 specifies is_convertible<From, To>. Both are specified in terms of "template <class T> typename add_rvalue_reference<T>::type create();". Therefore, passing From and From&& is equivalent, regardless of whether From is an object type, an lvalue reference, or an rvalue reference.

Also note that 20.4.2.1 [tuple.cnstr]/3 defines T0 and T1 so we don't need to repeat their definitions.

[2014-10-05, Daniel comments]

This issue is closely related to LWG 2419.

[2015-02, Cologne]

AM: Howard wants to do something in this space and I want to wait for him to get a paper in.

Postponed.

[2015-05, Lenexa]

MC: handled by Daniel's tuple paper N4387
STL: look at status after N4387 applied.

[2015-05-05, Daniel comments]

N4387 doesn't touch these area intentionally. I agree with Howard that a different option exists that would introduce a TupleLike concept. Some implementations currently take advantage of this choice and this P/R would forbid them, which seems unfortunate to me.

Proposed resolution:

This wording is relative to N3691.

  1. Edit 20.4.2.1 [tuple.cnstr] as indicated:

    template <class... UTypes>
      explicit constexpr tuple(UTypes&&... u);
    

    -8- Requires: sizeof...(Types) == sizeof...(UTypes). is_constructible<Ti, Ui&&>::value is true for all i.

    […]

    -10- Remark: This constructor shall not participate in overload resolution unless each type in UTypes is implicitly convertible to its corresponding type in Typessizeof...(Types) == sizeof...(UTypes) and both is_constructible<Ti, Ui>::value and is_convertible<Ui, Ti>::value are true for all i.

    […]

    template <class... UTypes>
      constexpr tuple(const tuple<UTypes...>& u);
    

    -15- Requires: sizeof...(Types) == sizeof...(UTypes). is_constructible<Ti, const Ui&>::value is true for all i.

    […]

    -17- Remark: This constructor shall not participate in overload resolution unless const Ui& is implicitly convertible to Tisizeof...(Types) == sizeof...(UTypes) and both is_constructible<Ti, const Ui&>::value and is_convertible<const Ui&, Ti>::value are true for all i.

    template <class... UTypes>
      constexpr tuple(tuple<UTypes...>&& u);
    

    -18- Requires: sizeof...(Types) == sizeof...(UTypes). is_constructible<Ti, Ui&&>::value is true for all i.

    […]

    -20- Remark: This constructor shall not participate in overload resolution unless each type in UTypes is implicitly convertible to its corresponding type in Typessizeof...(Types) == sizeof...(UTypes) and both is_constructible<Ti, Ui>::value and is_convertible<Ui, Ti>::value are true for all i.

    template <class U1, class U2> constexpr tuple(const pair<U1, U2>& u);
    

    -21- Requires: sizeof...(Types) == 2. is_constructible<T0, const U1&>::value is true for the first type T0 in Types and is_constructible<T1, const U2&>::value is true for the second type T1 in Types.

    […]

    -23- Remark: This constructor shall not participate in overload resolution unless const U1& is implicitly convertible to T0 and const U2& is implicitly convertible to T1sizeof...(Types) == 2 && is_constructible<T0, const U1&>::value && is_constructible<T1, const U2&>::value && is_convertible<const U1&, T0>::value && is_convertible<const U2&, T1>::value is true.

    template <class U1, class U2> constexpr tuple(pair<U1, U2>&& u);
    

    -24- Requires: sizeof...(Types) == 2. is_constructible<T0, U1&&>::value is true for the first type T0 in Types and is_constructible<T1, U2&&>::value is true for the second type T1 in Types.

    […]

    -26- Remark: This constructor shall not participate in overload resolution unless U1 is implicitly convertible to T0 and U2 is implicitly convertible to T1sizeof...(Types) == 2 && is_constructible<T0, U1>::value && is_constructible<T1, U2>::value && is_convertible<U1, T0>::value && is_convertible<U2, T1>::value is true.


2318. basic_string's wording has confusing relics from the copy-on-write era

Section: 21.4 [basic.string] Status: New Submitter: Stephan T. Lavavej Opened: 2013-09-21 Last modified: 2015-04-08

View other active issues in [basic.string].

View all other issues in [basic.string].

View all issues with New status.

Discussion:

21.4.4 [string.capacity]/8 specifies basic_string::resize(n, c) with:

Effects: Alters the length of the string designated by *this as follows:

This wording is a relic of the copy-on-write era. In addition to being extremely confusing, it has undesirable implications. Saying "replaces the string designated by *this with a string of length n whose elements are a copy" suggests that the trimming case can reallocate. Reallocation during trimming should be forbidden, like vector.

At least 7 paragraphs are affected: 21.4.4 [string.capacity]/8, 21.4.6.2 [string::append]/9, 21.4.6.3 [string::assign]/3 and /10, 21.4.6.4 [string::insert]/11, 21.4.6.5 [string::erase]/4, and 21.4.6.6 [string::replace]/11 say "replaces the string [designated/controlled] by *this". (21.4.6.7 [string::copy]/3 is different — it "replaces the string designated by s".)

Of the affected paragraphs, resize() and erase() are the most important to fix because they should forbid reallocation during trimming.

Proposed resolution:


2321. Moving containers should (usually) be required to preserve iterators

Section: 23.2.1 [container.requirements.general] Status: Open Submitter: Stephan T. Lavavej Opened: 2013-09-21 Last modified: 2015-04-08

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

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

View all issues with Open status.

Discussion:

23.2.1 [container.requirements.general]/10 says that unless otherwise specified, "no swap() function invalidates any references, pointers, or iterators referring to the elements of the containers being swapped. [Note: The end() iterator does not refer to any element, so it may be invalidated. — end note]". However, move constructors and move assignment operators aren't given similar invalidation guarantees. The guarantees need several exceptions, so I do not believe that blanket language like /11 "Unless otherwise specified (either explicitly or by defining a function in terms of other functions), invoking a container member function or passing a container as an argument to a library function shall not invalidate iterators to, or change the values of, objects within that container." is applicable.

[2014-02-13 Issaquah]

General agreeement on intent, several wording nits and additional paragraphs to hit.

STL to provide updated wording. Move to Open.

[2015-02, Cologne]

AM: in the proposed wording, I'd like to mention that the iterators now refer to elements of a different container. I think we're saying something like this somewhere. JY: There's some wording like that for swap I think. TK: It's also in list::splice(). DK to JY: 23.2.1p9.

VV: The issue says that STL was going to propose new wording. Has he done that? AM: I believe we're looking at that. GR: The request touches on multiple paragraphs, and this PR has only one new paragraph, so this looks like it's not up-to-date. MC: This was last updated a year ago in Issaquah.

Conclusion: Skip, not up to date.

Proposed resolution:

This wording is relative to N3691.

  1. In 23.2.1 [container.requirements.general]/10 change as indicated:

    -10- Unless otherwise specified (see 23.2.4.1, 23.2.5.1, 23.3.3.4, and 23.3.7.5) all container types defined in this Clause meet the following additional requirements:

    • […]

    • no copy constructor or assignment operator of a returned iterator throws an exception.

    • no move constructor (or move assignment operator when allocator_traits<allocator_type>::propagate_on_container_move_assignment::value is true) of a container (except for array) invalidates any references, pointers, or iterators referring to the elements of the source container. [Note: The end() iterator does not refer to any element, so it may be invalidated. — end note]

    • no swap() function throws an exception.

    • no swap() function invalidates any references, pointers, or iterators referring to the elements of the containers being swapped. [Note: The end() iterator does not refer to any element, so it may be invalidated. — end note]


2326. uniform_int_distribution<unsigned char> should be permitted

Section: 26.5.1.1 [rand.req.genl] Status: New Submitter: Stephan T. Lavavej Opened: 2013-09-21 Last modified: 2015-04-08

View all issues with New status.

Discussion:

26.5.1.1 [rand.req.genl]/1 says: "Throughout this subclause 26.5, the effect of instantiating a template [...] that has a template type parameter named IntType is undefined unless the corresponding template argument is cv-unqualified and is one of short, int, long, long long, unsigned short, unsigned int, unsigned long, or unsigned long long." 26.5.8.2.1 [rand.dist.uni.int] specifies template<class IntType = int> class uniform_int_distribution, so this forbids uniform_int_distribution<char/signed char/unsigned char>.

I am not aware of anything in <random> that works with 16-bit integers but fails with 8-bit integers, so I suspect that IntType and UIntType could simply be extended to permit the char family. Alternatively, this change could be limited to uniform_int_distribution alone, where it is definitely safe. A <random> expert should decide which change is best.

[2015-04-04 Geoffrey provides wording]

I think it's time to call the question; it's just silly that we have a random number library with no natural way to generate random bytes. However, I don't think it's sufficient to fix only uniform_int_distribution, or even all of IntType. At a bare minimum we need to also fix independent_bits_engine (arguably the cleanest way of generating a random byte) and that's specified in terms of UIntType.

The wording provided below is equivalent to adding unsigned char to item "f" and adding signed char and unsigned char to item "e". That means it still excludes char, but I'm OK with that. If you want to generate a 1-byte number, you should probably pick a signedess, and if you want to generate a raw byte, the "true" raw byte type is unsigned char. This also excludes extended integral types and wide char types, which seem like nice-to-haves at best. I have no objection to supporting any of those types; I just picked this to simplify the wording and hopefully maximize consensus. Note that if we want to broaden IntType to permit any integral type, we'll need to decide if we want to exclude bool.

For reference, IntType is used as a parameter of the following templates:

uniform_int_distribution
binomial_distribution
geometric_distribution
negative_binomial_distribution
poisson_distribution
discrete_distribution

and UIntType is used as a parameter of the following templates:

linear_congruential_engine
mersenne_twister_engine
subtract_with_carry_engine
independent_bits_engine

Proposed resolution:

This wording is relative to N4296.

  1. Change in 26.5.1.1 [rand.req.genl] p1 as indicated:

    -1- Throughout this subclause 26.5, the effect of instantiating a template:

    1. […]

    2. that has a template type parameter named IntType is undefined unless the corresponding template argument is cv-unqualified and is a standard integer type (3.9.1 [basic.fundamental])one of short, int, long, long long, unsigned short, unsigned int, unsigned long, or unsigned long long.

    3. that has a template type parameter named UIntType is undefined unless the corresponding template argument is cv-unqualified and is a standard unsigned integer type (3.9.1 [basic.fundamental])one of unsigned short, unsigned int, unsigned long, or unsigned long long.


2328. Rvalue stream extraction should use perfect forwarding

Section: 27.7.2.6 [istream.rvalue] Status: Review Submitter: Stephan T. Lavavej Opened: 2013-09-21 Last modified: 2015-05-22

View other active issues in [istream.rvalue].

View all other issues in [istream.rvalue].

View all issues with Review status.

Discussion:

27.7.2.6 [istream.rvalue] declares operator>>(basic_istream<charT, traits>&& is, T& x). However, 27.7.2.2.3 [istream::extractors]/7 declares operator>>(basic_istream<charT,traits>& in, charT* s), plus additional overloads for unsigned char* and signed char*. This means that "return_rvalue_istream() >> &arr[0]" won't compile, because T& won't bind to the rvalue &arr[0].

[2014-02-12 Issaquah : recategorize as P3]

Jonathan Wakely: Bill was certain the change is right, I think so with less certainty

Jeffrey Yaskin: I think he's right, hate that we need this

Jonathan Wakely: is this the security issue Jeffrey raised on lib reflector?

Move to P3

[2015-05-06 Lenexa: Move to Review]

WEB, MC: Proposed wording changes one signature (in two places) to take a forwarding reference.

TK: Should be consistent with an istream rvalue?

MC: This is the case where you pass the stream by rvalue reference.

RP: I would try it before standardizing.

TK: Does it break anything?

RP, TK: It will take all arguments, will be an exact match for everything.

RS, TK: This adapts streaming into an rvalue stream to make it act like streaming into an lvalue stream.

RS: Should this really return the stream by lvalue reference instead of by rvalue reference? => new LWG issue.

RP: Security issue?

MC: No. That's istream >> char*, C++ version of gets(). Remove it, as we did for gets()? => new LWG issue.

RS: Proposed resolution looks correct to me.

MC: Makes me (and Jonathan Wakely) feel uneasy.

Move to Review, consensus.

Proposed resolution:

This wording is relative to N3691.

  1. Edit 27.7.1 [iostream.format.overview], header <istream> synopsis, as indicated:

    namespace std {
      […]
      template <class charT, class traits, class T>
        basic_istream<charT, traits>&
        operator>>(basic_istream<charT, traits>&& is, T&& x);
    }
    
  2. Edit 27.7.2.6 [istream.rvalue] as indicated:

    template <class charT, class traits, class T>
      basic_istream<charT, traits>&
      operator>>(basic_istream<charT, traits>&& is, T&& x);
    

    -1- Effects: is >>x std::forward<T>(x)

    -2- Returns: is


2331. regex_constants::collate's effects are inaccurately summarized

Section: 28.5.1 [re.synopt] Status: Open Submitter: Stephan T. Lavavej Opened: 2013-09-21 Last modified: 2015-05-08

View other active issues in [re.synopt].

View all other issues in [re.synopt].

View all issues with Open status.

Discussion:

The table in 28.5.1 [re.synopt]/1 says that regex_constants::collate "Specifies that character ranges of the form "[a-b]" shall be locale sensitive.", but 28.13 [re.grammar]/14 says that it affects individual character comparisons too.

[2012-02-12 Issaquah : recategorize as P3]

Marshall Clow: 28.13/14 only applies to ECMAScript

All: we're unsure

Jonathan Wakely: we should ask John Maddock

Move to P3

[2014-5-14, John Maddock response]

The original intention was the original wording: namely that collate only made character ranges locale sensitive. To be frank it's a feature that's probably hardly ever used (though I have no real hard data on that), and is a leftover from early POSIX standards which required locale sensitive collation for character ranges, and then later changed to implementation defined if I remember correctly (basically nobody implemented locale-dependent collation).

So I guess the question is do we gain anything by requiring all character-comparisons to go through the locale when this bit is set? Certainly it adds a great deal to the implementation effort (it's not what Boost.Regex has ever done). I guess the question is are differing code-points that collate identically an important use case? I guess there might be a few Unicode code points that do that, but I don't know how to go about verifying that.

STL:

If this was unintentional, then 28.5.1 [re.synopt]/1's table should be left alone, while 28.13 [re.grammar]/14 should be changed instead.

Jeffrey Yasskin:

This page mentions that [V] in Swedish should match "W" in a perfect world.

However, the most recent version of TR18 retracts both language-specific loose matches and language-specific ranges because "for most full-featured regular expression engines, it is quite difficult to match under code point equivalences that are not 1:1" and "tailored ranges can be quite difficult to implement properly, and can have very unexpected results in practice. For example, languages may also vary whether they consider lowercase below uppercase or the reverse. This can have some surprising results: [a-Z] may not match anything if Z < a in that locale."

ECMAScript doesn't include collation at all.

IMO, +1 to changing 28.13 instead of 28.5.1. It seems like we'd be on fairly solid ground if we wanted to remove regex_constants::collate entirely, in favor of named character classes, but of course that's not for this issue.

Proposed resolution:

This wording is relative to N3691.

  1. In 28.5.1 [re.synopt]/1, Table 138 — "syntax_option_type effects", change as indicated:

    Table 138 — syntax_option_type effects
    Element Effect(s) if set
    collate Specifies that character ranges of the form "[a-b]"comparisons and character range comparisons shall be locale sensitive.

2335. array<array<int, 3>, 4> should be layout-compatible with int[4][3]

Section: 23.3.2 [array] Status: New Submitter: Jeffrey Yasskin Opened: 2013-10-04 Last modified: 2015-04-08

View other active issues in [array].

View all other issues in [array].

View all issues with New status.

Discussion:

In order to replace some uses of C arrays with std::array, we need it to be possible to cast from a std::array<> to an equivalent C array. Core wording doesn't appear to be in quite the right state to allow casting, but if we specify that appropriate types are layout-compatible, we can at least write:

union {
  array<array<array<int, 2>, 3>, 4> arr;
  int carr[4][3][2];
};

to view memory as the other type: C++14 CD [class.mem]p18.

I believe it's sufficient to add "array<T, N> shall be layout-compatible (3.9 [basic.types]) with T[N]." to 23.3.2.1 [array.overview], but we might also need some extension to 9.2 [class.mem] to address the possibility of layout-compatibility between struct and array types.

I checked that libc++ on MacOS already implements this, although it would be good for someone else to double-check; I haven't checked any other standard libraries.

Proposed resolution:


2338. [re.traits]/7 expects of locale facets something not guaranteed by [locale.facet]/4

Section: 28.7 [re.traits], 22.3.1.1.2 [locale.facet] Status: Open Submitter: Sergey Zubkov Opened: 2013-10-15 Last modified: 2015-05-22

View all other issues in [re.traits].

View all issues with Open status.

Discussion:

28.7 [re.traits]/7, begins with "if typeid(use_facet<collate<charT> >) == typeid(collate_byname<charT>)", which appears to be pseudocode with the intention to convey that the collate facet has not been replaced by the user. Cf. the wording in N1429 "there is no portable way to implement transform_primary in terms of std::locale, since even if the sort key format returned by std::collate_byname<>::transform is known and can be converted into a primary sort key, the user can still install their own custom std::collate implementation into the locale object used, and that can use any sort key format they see fit.".

Taken literally, 28.7 [re.traits]/7 appears to imply that named locales are required to hold their collate facets with dynamic type std::collate_byname<charT>, which is in fact true in some implementations (e.g libc++), but not others (e.g. libstdc++). This does not follow from the description of _byname in 22.3.1.1.2 [locale.facet]/4, which is only required to provide equivalent semantics, to the named locale's facet, not to actually be one.

[2015-05-06 Lenexa: Move to Open]

MC, RP: Consequence of failing to follow the rule is UB.

MC: Tightening of requirements.

RP: It should be this way, we just didn't impose it before.

MC: Second change is a bug fix, original code didn't work.

TK: Doesn't seem to make things worse.

Bring up in larger group tomorrow.

JW arrives.

JW: libstdc++ violates this due to two std::string ABIs.

JW: This prevents installing a type derived from Facet_byname, constrains the implementor from using a smarter derived class version.

JW: Can't look at facet id to detect replacement, because replacements have the same id.

RP: Can you give it multiple ids through multiple inheritance?

JW: No, the facet mechanism wouldn't like that.

JW: We should also ask Martin Sebor, he's implemented this stuff recently.

MC: Sounds like this resolution doesn't work, need a better solution.

JW: Write in words "if the facet has not been replaced by the user", the implementation knows how to detect that, but not like this.

RP: User RE traits need to detect this too.

JW: =(

Move to Open, JW will invite Martin Sebor to join LWG for discussion.

Later ...

JW: This is not needed for user specializations after all.

MC: Agree, [re.traits]/7 only applies to the stdlib traits.

NM: Effects: doesn't make sense.

JW, NM, Martin Sebor to come up with new wording.

Proposed resolution:

This wording is relative to N3691.

  1. Modify 22.3.1.1.2 [locale.facet]/4 as indicated:

    For some standard facets a standard "..._byname" class, derived from it, implements the virtual function semantics equivalent toprovided by that facet of the locale constructed by locale(const char*) with the same name. Each such facet provides a constructor that takes a const char* argument, which names the locale, and a refs argument, which is passed to the base class constructor. Each such facet also provides a constructor that takes a string argument str and a refs argument, which has the same effect as calling the first constructor with the two arguments str.c_str() and refs. If there is no "..._byname" version of a facet, the base class implements named locale semantics itself by reference to other facets. For any locale loc constructed by locale(const char*) and facet Facet that has a corresponding standard Facet_byname class, typeid(use_facet<Facet>(loc)) == typeid(Facet_byname).

  2. Modify 28.7 [re.traits]/7 as indicated:

    template <class ForwardIterator>
      string_type transform_primary(ForwardIterator first, ForwardIterator last) const;
    

    -7- Effects: if typeid(use_facet<collate<charT> >(getloc())) == typeid(collate_byname<charT>) and the form of the sort key returned by collate_byname<charT>::transform(first, last) is known and can be converted into a primary sort key then returns that key, otherwise returns an empty string.


2342. User conversion to wchar_t const* or to wchar_t not invoked for operator<<

Section: 27.7.3.1 [ostream] Status: New Submitter: Alf P. Steinbach Opened: 2013-10-29 Last modified: 2015-04-08

View all other issues in [ostream].

View all issues with New status.

Discussion:

For wide streams argument types wchar_t const* and wchar_t are supported only as template parameters. User defined conversions are not considered for template parameter matching. Hence inappropriate overloads of operator<< are selected when an implicit conversion is required for the argument, which is inconsistent with the behavior for char const* and char, is unexpected, and is a useless result.

Demonstration:

#include <iostream>

struct Byte_string
{ 
  operator char const*() const { return "Hurray, it works!"; } 
};

struct Wide_string
{ 
  operator wchar_t const*() const { return L"Hurray, it works!"; } 
};

struct Byte_ch
{ 
  operator char() const { return 'X'; } 
};

struct Wide_ch
{ 
  operator wchar_t() const { return L'X'; } 
};

auto main() -> int
{
  using namespace std;
  wcout << "'X' as char value   : " << Byte_ch() << endl;
  wcout << "'X' as wchar_t value: " << Wide_ch() << endl;
  wcout << "Byte string pointer : " << Byte_string() << endl;
  wcout << "Wide string pointer : " << Wide_string() << endl;
}

Example output:

'X' as char value   : X
'X' as wchar_t value: 88
Byte string pointer : Hurray, it works!
Wide string pointer : 000803C8

Proposed resolution:

This wording is relative to N3797.

  1. Modify 27.7.3.1 [ostream], class template basic_ostream synopsis, as indicated:

    namespace std {
    […]
    
    // 27.7.3.6.4 character inserters
    template<class charT, class traits>
      basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>&,
                                              charT);
    template<class charT, class traits>
      basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>&,
                                              char);
    template<class traits>
      basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>&,
                                             char);
    template<class traits>
      basic_ostream<wchar_t,traits>& operator<<(basic_ostream<wchar_t,traits>&,
                                                wchar_t);
    […]
    
    template<class charT, class traits>
      basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>&,
                                              const charT*);
    template<class charT, class traits>
      basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>&,
                                              const char*);
    template<class traits>
      basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>&,
                                             const char*);
    template<class traits>
      basic_ostream<wchar_t,traits>& operator<<(basic_ostream<wchar_t,traits>&,
                                                const wchar_t*);
    […]
    }
    
    
  2. Modify 27.7.3.6.4 [ostream.inserters.character] as indicated: [Drafting note: The replacement of os by out in p1 and the insertion of "out." in p4 just fix two obvious typos — end drafting note]

    template<class charT, class traits>
      basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>& out,
                                              charT c);
    template<class charT, class traits>
      basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>& out,
                                              char c);
    // specialization
    template<class traits>
      basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>& out,
                                             char c);
    template<class traits>
      basic_ostream<wchar_t,traits>& operator<<(basic_ostream<wchar_t,traits>& out,
                                                wchar_t c);
    
    // signed and unsigned
    template<class traits>
      basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>& out,
                                              signed char c);
    template<class traits>
      basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>& out,
                                              unsigned char c);
    

    -1- Effects: Behaves as a formatted output function (27.7.3.6.1 [ostream.formatted.reqmts]) of out. Constructs a character sequence seq. If c has type char and the character type of the stream is not char, then seq consists of out.widen(c); otherwise seq consists of c. Determines padding for seq as described in 27.7.3.6.1 [ostream.formatted.reqmts]. Inserts seq into out. Calls osout.width(0).

    -2- Returns: out.

    template<class charT, class traits>
      basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>& out,
                                              const charT* s);
    template<class charT, class traits>
      basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>& out,
                                              const char* s);
    template<class traits>
      basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>& out,
                                             const char* s);
    template<class traits>
      basic_ostream<wchar_t,traits>& operator<<(basic_ostream<wchar_t,traits>& out,
                                                const wchar_t* s);
    											
    template<class traits>
      basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>& out,
                                             const signed char* s);
    template<class traits>
      basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>& out,
                                             const unsigned char* s);
    

    -3- Requires: s shall not be a null pointer.

    -4- Effects: Behaves like a formatted inserter (as described in 27.7.3.6.1 [ostream.formatted.reqmts]) of out. Creates a character sequence seq of n characters starting at s, each widened using out.widen() (27.5.5.3), where n is the number that would be computed as if by:

    • traits::length(s) for the following overloads:

      • where the first argument is of type basic_ostream<charT, traits>& and the second is of type const charT*,

      • and also for the overload where the first argument is of type basic_ostream<char, traits>& and the second is of type const char*,

      • where the first argument is of type basic_ostream<wchar_t, traits>& and the second is of type const wchar_t*,

    • std::char_traits<char>::length(s) for the overload where the first argument is of type basic_ostream<charT, traits>& and the second is of type const char*,

    • traits::length(reinterpret_cast<const char*>(s)) for the other two overloads.

    Determines padding for seq as described in 27.7.3.6.1 [ostream.formatted.reqmts]. Inserts seq into out. Calls out.width(0).

    -5- Returns: out.


2343. Is the value of the ECMA-262 RegExp object's multiline property really false?

Section: 28.13 [re.grammar] Status: New Submitter: Nayuta Taga Opened: 2013-10-30 Last modified: 2015-05-22

View all other issues in [re.grammar].

View all issues with New status.

Discussion:

In the following "Multiline" is the value of the ECMA-262 RegExp object's multiline property.

In ECMA-262, there are some definitions that relate to Multiline:

So, the C++11 standard says that Multiline is false. As it is false, ^ matches only the beginning of the string, and $ matches only the end of the string.

However, two flags are defined in 28.5.2 [re.matchflag] Table 139:

match_not_bol: the character ^ in the regular expression shall not match [first,first).

match_not_eol: the character "$" in the regular expression shall not match [last,last).

As Multiline is false, the match_not_bol and the match_not_eol are meaningless because they only make ^ and $ match none.

In my opinion, Multiline should be true.

FYI, Multiline of the existing implementations are as follows:

Multiline=false:

Multiline=true:

[2015-05-22, Daniel comments]

This issue interacts with LWG 2503.

Proposed resolution:


2348. charT('1') is not the wide equivalent of '1'

Section: 20.6 [template.bitset], 27.7.6 [quoted.manip] Status: Open Submitter: Zhihao Yuan Opened: 2013-12-02 Last modified: 2015-05-22

View other active issues in [template.bitset].

View all other issues in [template.bitset].

View all issues with Open status.

Discussion:

Example: char16_t('1') != u'1' is possible.

The numeric value of char16_t is defined to be Unicode code point, which is same to the ASCII value and UTF-8 for 7-bit chars. However, char is not guaranteed to have an encoding which is compatible with ASCII. For example, '1' in EBCDIC is 241.

I found three places in the standard casting narrow char literals: bitset::bitset, bitset::to_string and quoted.

PJ confirmed this issue and says he has a solution used in their <filesystem> implementation, and he may want to propose it to the standard.

The solution in my mind, for now, is to make those default arguments magical, where the "magic" can be implemented with a C11 _Generic selection (works in clang):

#define _G(T, literal) _Generic(T{}, \
      char: literal, \
      wchar_t: L ## literal, \
      char16_t: u ## literal, \
      char32_t: U ## literal)

  _G(char16_t, '1') == u'1'

[Lenexa 2015-05-05: Move to Open]

Ask for complete PR (need quoted, to string, et al.)

Will then take it up again

Expectation is that this is correct way to fix this

Proposed resolution:

This wording is relative to N3797.

[Drafting note: This is a sample wording fixing only one case; I'm just too lazy to copy-paste it before we discussed whether the solution is worth and sufficient (for example, should the other `charT`s like `unsigned char` just don't compile without supplying those arguments? I hope so). — end drafting note]
  1. Modify 20.6 [template.bitset] p1, class template bitset synopsis, as indicated:

    namespace std {
      template <size_t N> class bitset {
      public:
        […]
        template<class charT, class traits, class Allocator>
          explicit bitset(
            const basic_string<charT,traits,Allocator>& str,
            typename basic_string<charT,traits,Allocator>::size_type pos = 0,
            typename basic_string<charT,traits,Allocator>::size_type n =
              basic_string<charT,traits,Allocator>::npos,
              charT zero = charT('0')see below, charT one = charT('1')see below);
         […]
      };
      […]
    }
    
  2. Modify 20.6.1 [bitset.cons] as indicated:

    template<class charT, class traits, class Allocator>
    explicit 
    bitset(const basic_string<charT, traits, Allocator>& str,
           typename basic_string<charT, traits, Allocator>::size_type pos = 0,
           typename basic_string<charT, traits, Allocator>::size_type n =
             basic_string<charT, traits, Allocator>::npos,
             charT zero = charT('0')see below, charT one = charT('1')see below);
    

    -?- The default values of zero and one compare equal to the character literals 0 and 1 of type charT, respectively.

    -3- Requires:: pos <= str.size().

    […]


2349. Clarify input/output function rethrow behavior

Section: 27.7.2.2.1 [istream.formatted.reqmts] Status: Open Submitter: Zhihao Yuan Opened: 2013-12-06 Last modified: 2015-05-22

View all other issues in [istream.formatted.reqmts].

View all issues with Open status.

Discussion:

The formatted input function requirement says in 27.7.2.2.1 [istream.formatted.reqmts]:

"If an exception is thrown during input then ios::badbit is turned on in *this's error state. If (exceptions()&badbit) != 0 then the exception is rethrown."

while some formatted function may throw an exception from basic_ios::clear, for example in 20.6.4 [bitset.operators] p6:

"If no characters are stored in str, calls is.setstate(ios_base::failbit) (which may throw ios_base::failure)"

So should this exception be considered as "an exception [...] thrown during input"? And here is an implementation divergence (or you can read the following as "a bug libc++ only has" :)

cin.exceptions(ios_base::failbit);
bitset<N> b;
try {
  cin >> b;  // type 'a' and return
} catch (...)
{}

Now cin.rdstate() is just failbit in libstdc++ (and Dinkumware, by PJ), but failbit & badbit libc++. Similar difference found in other places, like eofbit & badbid after std::getline.

PJ and Matt both agree that the intention (of badbit + rethrow) is "to signify an exception arising in user code, not the iostreams package".

In addition, I found the following words in unformatted input function's requirements (27.7.2.3 [istream.unformatted]):

If an exception is thrown during input then ios::badbit is turned on in *this's error state. (Exceptions thrown from basic_ios<>::clear() are not caught or rethrown.) If (exceptions()&badbit) != 0 then the exception is rethrown.

The content within the parenthesis is added by LWG defect 61, and does fix the ambiguity. However, it only fixed the 1 of 4 requirements, and it lost some context (the word "rethrown" is not seen before this sentence within this section).

[Lenexa 2015-05-07: Marshall to research and report]

Proposed resolution:

This wording is relative to N3797.

[Drafting note: The editor is kindly asked to introduce additional spaces at the following marked occurrences of operator&end drafting note]
  1. Modify 27.7.2.2.1 [istream.formatted.reqmts] p1 as indicated:

    -1- Each formatted input function begins execution by constructing an object of class sentry with the noskipws (second) argument false. If the sentry object returns true, when converted to a value of type bool, the function endeavors to obtain the requested input. If an exception, other than the ones thrown from clear(), if any, is thrown during input then ios::badbit is turned on[Footnote 314] in *this's error state. If (exceptions() & badbit) != 0 then the exception is rethrown. In any case, the formatted input function destroys the sentry object. If no exception has been thrown, it returns *this.

  2. Modify 27.7.3.6.1 [ostream.formatted.reqmts] p1 as indicated:

    -1- Each formatted output function begins execution by constructing an object of class sentry. If this object returns true when converted to a value of type bool, the function endeavors to generate the requested output. If the generation fails, then the formatted output function does setstate(ios_base::failbit), which might throw an exception. If an exception, other than the ones thrown from clear(), if any, is thrown during output, then ios::badbit is turned on[Footnote 327] in *this's error state. If (exceptions() & badbit) != 0 then the exception is rethrown. Whether or not an exception is thrown, the sentry object is destroyed before leaving the formatted output function. If no exception is thrown, the result of the formatted output function is *this.

  3. Modify 27.7.3.7 [ostream.unformatted] p1 as indicated:

    -1- Each unformatted output function begins execution by constructing an object of class sentry. If this object returns true, while converting to a value of type bool, the function endeavors to generate the requested output. If an exception, other than the ones thrown from clear(), if any, is thrown during output, then ios::badbit is turned on[Footnote 330] in *this's error state. If (exceptions() & badbit) != 0 then the exception is rethrown. In any case, the unformatted output function ends by destroying the sentry object, then, if no exception was thrown, returning the value specified for the unformatted output function.

  4. Modify 27.7.2.3 [istream.unformatted] p1 as indicated:

    -1- Each unformatted input function begins execution by constructing an object of class sentry with the default argument noskipws (second) argument true. If the sentry object returns true, when converted to a value of type bool, the function endeavors to obtain the requested input. Otherwise, if the sentry constructor exits by throwing an exception or if the sentry object returns false, when converted to a value of type bool, the function returns without attempting to obtain any input. In either case the number of extracted characters is set to 0; unformatted input functions taking a character array of non-zero size as an argument shall also store a null character (using charT()) in the first location of the array. If an exception, other than the ones thrown from clear(), if any, is thrown during input then ios::badbit is turned on[Footnote 317] in *this's error state. (Exceptions thrown from basic_ios<>::clear() are not caught or rethrown.) If (exceptions() & badbit) != 0 then the exception is rethrown. It also counts the number of characters extracted. If no exception has been thrown it ends by storing the count in a member object and returning the value specified. In any event the sentry object is destroyed before leaving the unformatted input function.


2352. Is a default-constructed std::seed_seq intended to produce a predictable .generate()?

Section: 26.5.7.1 [rand.util.seedseq] Status: New Submitter: Thomas Plum Opened: 2013-12-02 Last modified: 2015-04-08

View all other issues in [rand.util.seedseq].

View all issues with New status.

Discussion:

With respect to class seed_seq 26.5.7.1 [rand.util.seedseq], is a default-constructed std::seed_seq intended to produce a predictable .generate() sequence?

Implementations differ.

Proposed resolution:


2358. Apparently-bogus definition of is_empty type trait

Section: 20.10.4.3 [meta.unary.prop] Status: New Submitter: Richard Smith Opened: 2014-02-01 Last modified: 2015-04-08

View other active issues in [meta.unary.prop].

View all other issues in [meta.unary.prop].

View all issues with New status.

Discussion:

The 'Condition' for std::is_empty is listed as:

"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."

This is incorrect: there is no such thing as a non-static data member that is a bit-field of length 0, since bit-fields of length 0 must be unnamed, and unnamed bit-fields are not members (see 9.6 [class.bit] p2).

It also means that classes such as:

struct S {
 int : 3;
};

are empty (because they have no non-static data members). There's implementation divergence on the value of is_empty<S>::value.

I'm not sure what the purpose of is_empty is (or how it could be useful), but if it's desirable for the above type to not be treated as empty, something like this could work:

"T is a class type, but not a union type, with no non-static data members other than, no unnamed bit-fields of non-zero length 0, no virtual member functions, no virtual base classes, and no base class B for which is_empty<B>::value is false."

and if the above type should be treated as empty, then this might be appropriate:

"T is a class type, but not a union type, with no (named) 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."

Proposed resolution:


2362. unique, associative emplace() should not move/copy the mapped_type constructor arguments when no insertion happens

Section: 23.2.4 [associative.reqmts], 23.2.5 [unord.req] Status: New Submitter: Jeffrey Yasskin Opened: 2014-02-15 Last modified: 2015-04-08

View other active issues in [associative.reqmts].

View all other issues in [associative.reqmts].

View all issues with New status.

Discussion:

a_uniq.emplace(args) is specified as:

Effects: Inserts a value_type 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.

However, we occasionally find code of the form:

std::unique_ptr<Foo> p(new Foo);
auto res = m.emplace("foo", std::move(p));

where we'd like to avoid destroying the Foo if the insertion doesn't take place (if the container already had an element with the specified key).

N3873 includes a partial solution to this in the form of a new emplace_stable member function, but LEWG's discussion strongly agreed that we'd rather have emplace() Just Work:

Should map::emplace() be guaranteed not to move/copy its arguments if the insertion doesn't happen?

SF: 8 F: 3 N: 0 A: 0 SA: 0

This poll was marred by the fact that we didn't notice or call out that emplace() must construct the key before doing the lookup, and it must not then move the key after it determines whether an insert is going to happen, and the mapped_type instance must live next to the key.

The very similar issue 2006 was previously marked NAD, with N3178 as discussion. However, given LEWG's interest in the alternate behavior, we should reopen the question in this issue.

We will need a paper that describes how to implement this before we can make more progress.

Proposed resolution:


2363. Defect in 30.4.1.4.1 [thread.sharedtimedmutex.class]

Section: 30.4.1.5.1 [thread.sharedtimedmutex.class] Status: Open Submitter: Richard Smith Opened: 2014-02-16 Last modified: 2015-05-08

View all issues with Open status.

Discussion:

30.4.1.5.1 [thread.sharedtimedmutex.class] paragraph 2:

The class shared_timed_mutex shall satisfy all of the SharedTimedMutex requirements (30.4.1.4). It shall be a standard layout class (Clause 9).

There's no SharedTimedMutex requirements; this name doesn't appear anywhere else in the standard. (Prior to N3891, this was SharedMutex, which was equally undefined.)

I assume this concept should be defined somewhere?

Also, n3891 changes 30.4.1.5 [thread.sharedtimedmutex.requirements] from defining "shared mutex type" to defining "shared timed mutex type", but its paragraph 2 still talks about "shared mutex type". Is that OK? I think you could argue that it's clear enough what it means, but presumably it should use the term that paragraph 1 defined.

30.4.2.3 [thread.lock.shared] paragraph 1 talks about the "shared mutex requirements", which again is a term that isn't defined, and presumably means "the requirements on a shared timed mutex type" or similar (maybe if SharedMutex or SharedTimedMutex were defined it could be reused here).

[2014-05-22, Daniel comments]

As for SharedTimedMutex, there exists a similar problem in regard to TimedMutex referred to in 30.4.1.3.1 [thread.timedmutex.class] p2 and in 30.4.1.3.2 [thread.timedmutex.recursive] p2, but nowhere defined.

Another problem is, that according to 30.4.1.2.1 [thread.mutex.class] p3, "The class mutex shall satisfy all the Mutex requirements (30.4.1 [thread.mutex.requirements]).", but there are no concrete Mutex requirements, 30.4.1 [thread.mutex.requirements] — titled as "Mutex requirements" — describes mutex types, timed mutex types, and shared timed mutex types.

[2014-06-08, Daniel comments and provides wording]

The presented wording adds to the existing mutex types, timed mutex types, and shared timed mutex types terms a new set of corresponding MutexType, TimedMutexType, and SharedTimedMutexType requirements.

The reason for the change of requirement names is two-fold: First, the new name better matches the intention to have a concrete name for the requirements imposed on the corresponding mutex types (This kind of requirement deviate from the more general Lockable requirements, which are not restricted to a explicitly enumerated set of library types). Second, using **MutexType over **Mutex provides the additional advantage that it reduces the chances of confusing named requirements from template parameters named Mutex (such as for unique_lock or shared_lock).

Nonetheless the here presented wording has one unfortunate side-effect: Once applied it would have the effect that types used to instantiate std::shared_lock cannot be user-defined shared mutex types due to 30.4.2.3 [thread.lock.shared]. The reason is based on the currently lack of an existing SharedLockable requirement set, which would complete the existing BasicLockable and Lockable requirements (which are "real" requirements). This restriction is not actually a problem introduced by the provided resolution but instead one that existed before but becomes more obvious now.

[2015-02 Cologne]

Handed over to SG1.

[2015-05 Lenexa, SG1 response]

Thanks to Daniel, and please put it in SG1-OK status. Perhaps open another issue for the remaining problem Daniel points out?

Proposed resolution:

This wording is relative to N3936.

  1. Change 30.4.1.2 [thread.mutex.requirements.mutex] as indicated:

    -1- The mutex types are the standard library types std::mutex, std::recursive_mutex, std::timed_mutex, std::recursive_timed_mutex, and std::shared_timed_mutex. They shall meet the MutexType requirements set out in this section. In this description, m denotes an object of a mutex type.

  2. Change 30.4.1.2.1 [thread.mutex.class] as indicated:

    -3- The class mutex shall satisfy all the MutexType requirements (30.4.1.2 [thread.mutex.requirements.mutex]30.4.1 [thread.mutex.requirements]). It shall be a standard-layout class (Clause 9).

  3. Change 30.4.1.2.2 [thread.mutex.recursive] as indicated:

    -2- The class recursive_mutex shall satisfy all the MutexMutexType requirements (30.4.1.2 [thread.mutex.requirements.mutex]30.4.1 [thread.mutex.requirements]). It shall be a standard-layout class (Clause 9).

  4. Change 30.4.1.3 [thread.timedmutex.requirements] as indicated:

    -1- The timed mutex types are the standard library types std::timed_mutex, std::recursive_timed_mutex, and std::shared_timed_mutex. They shall meet the TimedMutexType requirements set out below. In this description, m denotes an object of a mutex type, rel_time denotes an object of an instantiation of duration (20.12.5), and abs_time denotes an object of an instantiation of time_point (20.12.6).

  5. Change 30.4.1.3.1 [thread.timedmutex.class] as indicated:

    -2- The class timed_mutex shall satisfy all of the TimedMutexType requirements (30.4.1.3 [thread.timedmutex.requirements]). It shall be a standard-layout class (Clause 9).

  6. Change 30.4.1.3.2 [thread.timedmutex.recursive] as indicated:

    -2- The class recursive_timed_mutex shall satisfy all of the TimedMutexType requirements (30.4.1.3 [thread.timedmutex.requirements]). It shall be a standard-layout class (Clause 9).

  7. Change 30.4.1.5 [thread.sharedtimedmutex.requirements] as indicated: [Drafting note: The reference to the timed mutex types requirements has been moved after introducing the new requirement set to ensure that SharedTimedMutexType refine TimedMutexType.]

    -1- The standard library type std::shared_timed_mutex is a shared timed mutex type. Shared timed mutex types shall meet the SharedTimedMutexType requirements of timed mutex types (30.4.1.3 [thread.timedmutex.requirements]), and additionally shall meet the requirements set out below. In this description, m denotes an object of a mutex type, rel_type denotes an object of an instantiation of duration (20.12.5), and abs_time denotes an object of an instantiation of time_point (20.12.6).

    -?- The shared timed mutex types shall meet the TimedMutexType requirements (30.4.1.3 [thread.timedmutex.requirements]).

  8. Change 30.4.1.5.1 [thread.sharedtimedmutex.class] as indicated:

    -2- The class shared_timed_mutex shall satisfy all of the SharedTimedMutexType requirements (30.4.1.5 [thread.sharedtimedmutex.requirements]). It shall be a standard-layout class (Clause 9).

  9. Change 30.4.2.3 [thread.lock.shared] as indicated: [Drafting note: Once N3995 has been applied, the following reference should be changed to the new SharedMutexType requirements ([thread.sharedmutex.requirements]) or even better to some new SharedLockable requirements (to be defined) — end drafting note]

    -1- […] The supplied Mutex type shall meet the shared mutexSharedTimedMutexType requirements (30.4.1.5 [thread.sharedtimedmutex.requirements]).

    -2- [Note: shared_lock<Mutex> meets the TimedLockable requirements (30.2.5.4). — end note]


2366. istreambuf_iterator end-of-stream equality

Section: 24.6.3 [istreambuf.iterator] Status: New Submitter: Hyman Rosen Opened: 2014-02-19 Last modified: 2015-04-08

View all other issues in [istreambuf.iterator].

View all issues with New status.

Discussion:

Given the following code,

#include <sstream>

std::stringbuf buf;
std::istreambuf_iterator<char> begin(&buf);
std::istreambuf_iterator<char> end;

it is not clear from the wording of the Standard whether begin.equal(end) must be true. In at least one implementation it is not (CC: Sun C++ 5.10 SunOS_sparc Patch 128228-25 2013/02/20) and in at least one implementation it is (gcc version 4.3.2 x86_64-unknown-linux-gnu).

24.6.3 [istreambuf.iterator] says that end is an end-of-stream iterator since it was default constructed. It also says that an iterator becomes equal to an end-of-stream iterator when end of stream is reached by sgetc() having returned eof(). 24.6.3.5 [istreambuf.iterator::equal] says that equal() returns true iff both iterators are end of stream or not end of stream. But there seems to be no requirement that equal check for end-of-stream by calling sgetc().

Jiahan Zi at BloombergLP discovered this issue through his code failing to work correctly. Dietmar Kühl has opined in a private communication that the iterators should compare equal.

Proposed resolution:


2368. Replacing global operator new

Section: 18.6.1 [new.delete] Status: New Submitter: Stephen Clamage Opened: 2014-02-20 Last modified: 2015-04-08

View all other issues in [new.delete].

View all issues with New status.

Discussion:

Section 18.6.1 [new.delete] and subsections shows:

void* operator new(std::size_t size);
void* operator new[](std::size_t size);

That is, without exception-specifications. (Recall that C++03 specified these functions with throw(std::bad_alloc).)

Section 17.6.5.12 [res.on.exception.handling] the end of paragraph 4 says:

Any other functions defined in the C++ standard library that do not have an exception-specification may throw implementation-defined exceptions unless otherwise specified. An implementation may strengthen this implicit exception-specification by adding an explicit one.

For example, an implementation could provide C++03-compatible declarations of operator new.

Programmers are allowed to replace these operator new functions. But how can you write the definition of these functions when the exception specification can vary among implementations? For example, the declarations

void* operator new(std::size_t size) throw(std::bad_alloc);
void* operator new(std::size_t size);

are not compatible.

From what I have been able to determine, gcc has a hack for the special case of operator new to ignore the differences in (at least) the two cases I show above. But can users expect all compilers to quietly ignore the incompatibility?

The blanket permission to add any explicit exception specification could cause a problem for any user-overridable function. Different implementations could provide incompatible specifications, making portable code impossible to write.

Proposed resolution:


2370. Operations involving type-erased allocators should not be noexcept in std::function

Section: 20.9.12.2 [func.wrap.func] Status: Open Submitter: Pablo Halpern Opened: 2014-02-27 Last modified: 2015-05-05

View other active issues in [func.wrap.func].

View all other issues in [func.wrap.func].

View all issues with Open status.

Discussion:

The following constructors in 20.9.12.2 [func.wrap.func] are declared noexcept, even though it is not possible for an implementation to guarantee that they will not throw:

template <class A> function(allocator_arg_t, const A&) noexcept;
template <class A> function(allocator_arg_t, const A&, nullptr_t) noexcept;

In addition, the following functions are guaranteed not to throw if the target is a function pointer or a reference_wrapper:

template <class A> function(allocator_arg_t, const A& a, const function& f);
template <class F, class A> function(allocator_arg_t, const A& a, F f);

In all of the above cases, the function object might need to allocate memory (an operation that can throw) in order to hold a copy of the type-erased allocator itself. The first two constructors produce an empty function object, but the allocator is still needed in case the object is later assigned to. In this case, we note that the propagation of allocators on assignment is underspecified for std::function. There are three possibilities:

  1. The allocator is never copied on copy-assignment, moved on move-assignment, or swapped on swap.

  2. The allocator is always copied on copy-assignment, moved on move-assignment, and swapped on swap.

  3. Whether or not the allocator is copied, moved, or swapped is determined at run-time based on the propagate_on_container_copy_assignment and propagate_on_container_move_assignment traits of the allocators at construction of the source function, the target function, or both.

Although the third option seems to be the most consistent with existing wording in the containers section of the standard, it is problematic in a number of respects. To begin with, the propagation behavior is determined at run time based on a pair of type-erased allocators, instead of at compile time. Such run-time logic is not consistent with the rest of the standard and is hard to reason about. Additionally, there are two allocator types involved, rather than one. Any set of rules that attempts to rationally interpret the propagation traits of both allocators is likely to be arcane at best, and subtly wrong for some set of codes at worst.

The second option is a non-starter. Historically, and in the vast majority of existing code, an allocator does not change after an object is constructed. The second option, if adopted, would undermine the programmer's ability to construct, e.g., an array of function objects, all using the same allocator.

The first option is (in Pablo's opinion) the simplest and best. It is consistent with historical use of allocators, is easy to understand, and requires minimal wording. It is also consistent with the wording in N3916, which formalizes type-erased allocators.

For cross-referencing purposes: The resolution of this issue should be harmonized with any resolution to LWG 2062, which questions the noexcept specification on the following member functions of std::function:

template <class F> function& operator=(reference_wrapper<F>) noexcept;
void swap(function&) noexcept;

[2015-05, Lenexa]

MC: change to P3 and status to open.

STL: note that noexcept is an issue and large chunks of allocator should be destroyed.

Proposed resolution:

This wording is relative to N3936.

  1. Change 20.9.12.2 [func.wrap.func], class template function synopsis, as indicated:

    template <class A> function(allocator_arg_t, const A&) noexcept;
    template <class A> function(allocator_arg_t, const A&, nullptr_t) noexcept;
    
  2. Change 20.9.12.2.1 [func.wrap.func.con] as indicated:

    -1- When any function constructor that takes a first argument of type allocator_arg_t is invoked, the second argument shall have a type that conforms to the requirements for Allocator (Table 17.6.3.5). A copy of the allocator argument is used to allocate memory, if necessary, for the internal data structures of the constructed function object. For the remaining constructors, an instance of allocator<T>, for some suitable type T, is used to allocate memory, if necessary, for the internal data structures of the constructed function object.

    function() noexcept;
    template <class A> function(allocator_arg_t, const A&) noexcept;
    

    -2- Postconditions: !*this.

    function(nullptr_t) noexcept;
    template <class A> function(allocator_arg_t, const A&, nullptr_t) noexcept;
    

    -3- Postconditions: !*this.

    function(const function& f);
    template <class A> function(allocator_arg_t, const A& a, const function& f);
    

    -4- Postconditions: !*this if !f; otherwise, *this targets a copy of f.target().

    -5- Throws: shall not throw exceptions if f's target is a callable object passed via reference_wrapper or a function pointer. Otherwise, may throw bad_alloc or any exception thrown by the copy constructor of the stored callable object. [Note: Implementations are encouraged to avoid the use of dynamically allocated memory for small callable objects, for example, where f's target is an object holding only a pointer or reference to an object and a member function pointer. — end note]

    template <class A> function(allocator_arg_t, const A& a, const function& f);
    

    -?- Postconditions: !*this if !f; otherwise, *this targets a copy of f.target().

    function(function&& f);
    template <class A> function(allocator_arg_t, const A& a, function&& f);
    

    -6- Effects: If !f, *this has no target; otherwise, move-constructs the target of f into the target of *this, leaving f in a valid state with an unspecified value. If an allocator is not specified, the constructed function will use the same allocator as f.

    template<class F> function(F f);
    template <class F, class A> function(allocator_arg_t, const A& a, F f);
    

    -7- Requires: F shall be CopyConstructible.

    -8- Remarks: These constructors shall not participate in overload resolution unless f is Callable (20.9.11.2) for argument types ArgTypes... and return type R.

    -9- Postconditions: !*this if any of the following hold:

    • f is a null function pointer value.

    • f is a null member pointer value.

    • F is an instance of the function class template, and !f

    -10- Otherwise, *this targets a copy of f initialized with std::move(f). [Note: Implementations are encouraged to avoid the use of dynamically allocated memory for small callable objects, for example, where f's target is an object holding only a pointer or reference to an object and a member function pointer. — end note]

    -11- Throws: shall not throw exceptions when an allocator is not specified and f is a function pointer or a reference_wrapper<T> for some T. Otherwise, may throw bad_alloc or any exception thrown by F's copy or move constructor or by A's allocate function.


2375. Is [iterator.requirements.general]/9 too broadly applied?

Section: 24.2.1 [iterator.requirements.general] Status: New Submitter: Marshall Clow Opened: 2014-03-25 Last modified: 2015-04-08

View all issues with New status.

Discussion:

24.2.1 [iterator.requirements.general] p9 says:

Destruction of an iterator may invalidate pointers and references previously obtained from that iterator.

But the resolution of LWG issue 2360 specifically advocates returning *--temp; where temp is a local variable.

And 24.2.5 [forward.iterators] p6 says:

If a and b are both dereferenceable, then a == b if and only if *a and *b are bound to the same object.

which disallows "stashing" iterators (i.e, iterators that refer to data inside themselves).

So, I suspect that the restriction in p9 should only apply to input iterators, and can probably be moved into 24.2.3 [input.iterators] instead of 24.2.1 [iterator.requirements.general].

[2014-05-22, Daniel comments]

Given that forward iterators (and beyond) are refinements of input iterator, moving this constraint to input iterators won't help much because it would still hold for all refined forms.

Proposed resolution:


2379. Obtaining native handle of the current thread

Section: 30.2.3 [thread.req.native], 30.3.2 [thread.thread.this] Status: Open Submitter: Matt Austern Opened: 2014-03-31 Last modified: 2015-05-08

View all issues with Open status.

Discussion:

Class thread contains an implementation-defined type thread::native_handle_type, and an implementation-defined function thread::native_handle() that returns a value of that type. The presence and semantics of those members is implementation-defined; the intention is that they can be used for interoperability with libraries that rely on operating system specific features. (Posix libraries that accept arguments of type pthread_t, for example.)

Unfortunately, there appears to be no native handle support for the equivalent of pthread_self(). We can use this_thread::get_id() to obtain the thread::id of the current thread, but there is no mechanism for converting a thread::id to a thread::native_handle.

Proposed wording:

In 30.3.2 [thread.thread.this] add:

thread::native_handle_type native_handle(); // See 30.2.3

to the this_thread namespace synopsis.

Rationale:

Informally, we could address this issue either by adding a new function in this_thread or by providing a mechanism for converting between thread::id and thread::native_handle. I propose the former because it seems more localized, and doesn't involve saying anything more about implementation defined native functionality than we currently do.

It's intentional that the proposed resolution adds a declaration of native_handle() without adding a paragraph explaining what it does. This is because everything about native_handle() is implementation-defined. The standard does the same thing in 30.3.1.5 [thread.thread.member].

[2015-02 Cologne]

Handed over to SG1.

[2015-05 Lenexa, SG1 response]

Strong "don't care" reaction from SG1, after pointing out that this only matters in non-portable code, which can call pthread_self() or the like anyway, but the change also doesn't add any non-trivial implementation requirements. This defused initial strong opinions on both sides. Since this is essentially a feature request, we did not have sufficient consensus to proceed at this point. There was a feeling we should reconsider after making more sense out of the much more general TLS issues we have been discussing.

Proposed resolution:

This wording is relative to N3936.

  1. Change 30.2.3 [thread.req.native] p1 as indicated:

    -1- Several classes described in this Clause have membersThis Clause includes several members named native_handle_type and native_handle. The presence of these members and their semantics is implementation-defined. […]

  2. In 30.3 [thread.threads], header <thread> synopsis, add:

    namespace std {
      […]
      namespace this_thread {
        thread::id get_id() noexcept;
        thread::native_handle_type native_handle();
        […]
      }
    }
    
  3. In 30.3.2 [thread.thread.this] add:

    namespace std {
      namespace this_thread {
        thread::id get_id() noexcept;
        thread::native_handle_type native_handle(); // See 30.2.3 [thread.req.native]
        […]
      }
    }
    

2381. Inconsistency in parsing floating point numbers

Section: 22.4.2.1.2 [facet.num.get.virtuals] Status: New Submitter: Marshall Clow Opened: 2014-04-30 Last modified: 2015-04-08

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

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

View all issues with New status.

Discussion:

In 22.4.2.1.2 [facet.num.get.virtuals] we have:

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>:

This implies that for many cases, this routine should return true:

bool is_same(const char* p) 
{
  std::string str{p};
  double val1 = std::strtod(str.c_str(), nullptr);
  std::stringstream ss(str);
  double val2;
  ss >> val2;
  return std::isinf(val1) == std::isinf(val2) &&                 // either they're both infinity
         std::isnan(val1) == std::isnan(val2) &&                 // or they're both NaN
         (std::isinf(val1) || std::isnan(val1) || val1 == val2); // or they're equal
}

and this is indeed true, for many strings:

assert(is_same("0"));
assert(is_same("1.0"));
assert(is_same("-1.0"));
assert(is_same("100.123"));
assert(is_same("1234.456e89"));

but not for others

assert(is_same("0xABp-4")); // hex float
assert(is_same("inf"));
assert(is_same("+inf"));
assert(is_same("-inf"));
assert(is_same("nan"));
assert(is_same("+nan"));
assert(is_same("-nan"));

assert(is_same("infinity"));
assert(is_same("+infinity"));
assert(is_same("-infinity"));

These are all strings that are correctly parsed by std::strtod, but not by the stream extraction operators. They contain characters that are deemed invalid in stage 2 of parsing.

If we're going to say that we're converting by the rules of strtold, then we should accept all the things that strtold accepts.

Proposed resolution:


2383. Overflow cannot be ill-formed for chrono::duration integer literals

Section: 20.12.5.8 [time.duration.literals] Status: Open Submitter: Jonathan Wakely Opened: 2014-05-16 Last modified: 2015-04-08

View all issues with Open status.

Discussion:

20.12.5.8 [time.duration.literals] p3 says:

If any of these suffixes are applied to an integer literal and the resulting chrono::duration value cannot be represented in the result type because of overflow, the program is ill-formed.

Ill-formed requires a diagnostic at compile-time, but there is no way to detect the overflow from unsigned long long to the signed duration<>::rep type.

Overflow could be detected if the duration integer literals were literal operator templates, otherwise overflow can either be undefined or a run-time error, not ill-formed.

[Urbana 2014-11-07: Move to Open]

Proposed resolution:


2392. "character type" is used but not defined

Section: 17.3 [defns.ntcts], 22.3.1.1.1 [locale.category], 27.2.2 [iostreams.limits.pos], 27.7.3.6.1 [ostream.formatted.reqmts], 27.7.3.6.4 [ostream.inserters.character] Status: New Submitter: Jeffrey Yasskin Opened: 2014-06-01 Last modified: 2015-04-08

View all issues with New status.

Discussion:

The term "character type" is used in 17.3 [defns.ntcts], 22.3.1.1.1 [locale.category], 27.2.2 [iostreams.limits.pos], 27.7.3.6.1 [ostream.formatted.reqmts], and 27.7.3.6.4 [ostream.inserters.character], but the core language only defines "narrow character types" (3.9.1 [basic.fundamental]).

"wide-character type" is used in 22.5 [locale.stdcvt], but the core language only defines a "wide-character set" and "wide-character literal".

Proposed resolution:


2393. std::function's Callable definition is broken

Section: 20.9.12.2 [func.wrap.func] Status: Open Submitter: Daniel Krügler Opened: 2014-06-03 Last modified: 2015-04-08

View other active issues in [func.wrap.func].

View all other issues in [func.wrap.func].

View all issues with Open status.

Discussion:

The existing definition of std::function's Callable requirements provided in 20.9.12.2 [func.wrap.func] p2,

A callable object f of type F is Callable for argument types ArgTypes and return type R if the expression INVOKE(f, declval<ArgTypes>()..., R), considered as an unevaluated operand (Clause 5), is well formed (20.9.2).

is defective in several aspects:

  1. The wording can be read to be defined in terms of callable objects, not of callable types.

  2. Contrary to that, 20.9.12.2.5 [func.wrap.func.targ] p2 speaks of "T shall be a type that is Callable (20.9.11.2) for parameter types ArgTypes and return type R."

  3. The required value category of the callable object during the call expression (lvalue or rvalue) strongly depends on an interpretation of the expression f and therefore needs to be specified unambiguously.

The intention of original proposal (see IIIa. Relaxation of target requirements) was to refer to both types and values ("we say that the function object f (and its type F) is Callable […]"), but that mental model is not really deducible from the existing wording. An improved type-dependence wording would also make the sfinae-conditions specified in 20.9.12.2.1 [func.wrap.func.con] p8 and p21 ("[…] shall not participate in overload resolution unless f is Callable (20.9.11.2) for argument types ArgTypes... and return type R.") easier to interpret.

My understanding always had been (see e.g. Howard's code example in the 2009-05-01 comment in LWG 815), that std::function invokes the call operator of its target via an lvalue. The required value-category is relevant, because it allows to reflect upon whether an callable object such as

struct RVF 
{
  void operator()() const && {}
};

would be a feasible target object for std::function<void()> or not.

Clarifying the current Callable definition seems also wise to make a future transition to language-based concepts easier. A local fix of the current wording is simple to achieve, e.g. by rewriting it as follows:

A callable object f of type (20.9.1 [func.def]) F is Callable for argument types ArgTypes and return type R if the expression INVOKE(fdeclval<F&>(), declval<ArgTypes>()..., R), considered as an unevaluated operand (Clause 5), is well formed (20.9.2).

It seems appealing to move such a general Callable definition to a more "fundamental" place (e.g. as another paragraph of 20.9.1 [func.def]), but the question arises, whether such a more general concept should impose the requirement that the call expression is invoked on an lvalue of the callable object — such a special condition would also conflict with the more general definition of the result_of trait, which is defined for either lvalues or rvalues of the callable type Fn. In this context I would like to point out that "Lvalue-Callable" is not the one and only Callable requirement in the library. Counter examples are std::thread, call_once, or async, which depend on "Rvalue-Callable", because they all act on functor rvalues, see e.g. 30.3.1.2 [thread.thread.constr]:

[…] The new thread of execution executes INVOKE(DECAY_COPY(std::forward<F>(f)), DECAY_COPY(std::forward<Args>(args))...) […]

For every callable object F, the result of DECAY_COPY is an rvalue. These implied rvalue function calls are no artifacts, but had been deliberately voted for by a Committee decision (see LWG 2021, 2011-06-13 comment) and existing implementations respect these constraints correctly. Just to give an example,

#include <thread>

struct LVF 
{
  void operator()() & {}
};

int main()
{
  LVF lf;
  std::thread t(lf);
  t.join();
}

is supposed to be rejected.

The below presented wording changes are suggested to be minimal (still local to std::function), but the used approach would simplify a future (second) conceptualization or any further generalization of Callable requirements of the Library.

[2015-02 Cologne]

Related to N4348. Don't touch with a barge pole.

Proposed resolution:

This wording is relative to N3936.

  1. Change 20.9.12.2 [func.wrap.func] p2 as indicated:

    -2- A callable object f of type (20.9.1 [func.def]) F is Lvalue-Callable for argument types ArgTypes and return type R if the expression INVOKE(fdeclval<F&>(), declval<ArgTypes>()..., R), considered as an unevaluated operand (Clause 5), is well formed (20.9.2).

  2. Change 20.9.12.2.1 [func.wrap.func.con] p8+p21 as indicated:

    template<class F> function(F f);
    template <class F, class A> function(allocator_arg_t, const A& a, F f);
    

    […]

    -8- Remarks: These constructors shall not participate in overload resolution unless fF is Lvalue-Callable (20.9.11.2) for argument types ArgTypes... and return type R.

    […]

    template<class F> function& operator=(F&& f);
    

    […]

    -21- Remarks: This assignment operator shall not participate in overload resolution unless declval<typename decay<F>::type&>()decay_t<F> is Lvalue-Callable (20.9.11.2) for argument types ArgTypes... and return type R.

  3. Change 20.9.12.2.5 [func.wrap.func.targ] p2 as indicated: [Editorial comment: Instead of adapting the preconditions for the naming change I recommend to strike it completely, because the target() functions do not depend on it; the corresponding wording exists since its initial proposal and it seems without any advantage to me. Assume that some template argument T is provided, which does not satisfy the requirements: The effect will be that the result is a null pointer value, but that case can happen in other (valid) situations as well. — end comment]

    template<class T> T* target() noexcept;
    template<class T> const T* target() const noexcept;
    

    -2- Requires: T shall be a type that is Callable (20.9.11.2) for parameter types ArgTypes and return type R.

    -3- Returns: If target_type() == typeid(T) a pointer to the stored function target; otherwise a null pointer.


2394. locale::name specification unclear — what is implementation-defined?

Section: 22.3.1.3 [locale.members] Status: New Submitter: Richard Smith Opened: 2014-06-09 Last modified: 2015-04-08

View all other issues in [locale.members].

View all issues with New status.

Discussion:

22.3.1.3 [locale.members] p5 says:

Returns: The name of *this, if it has one; otherwise, the string "*". If *this has a name, then locale(name().c_str()) is equivalent to *this. Details of the contents of the resulting string are otherwise implementation-defined.

So… what is implementation-defined here, exactly? The first sentence completely defines the behavior of this function in all cases.

Also, the second sentence says (effectively) that all locales with the same name are equivalent: given L1 and L2 that have the same name N, they are both equivalent to locale(N), and since there is no definition of "equivalent" specific to locale, I assume it's the normal transitive equivalence property, which would imply that L1 is equivalent to L2. I'm not sure why this central fact is in the description of locale::name, nor why it's written in this roundabout way.

Proposed resolution:


2398. type_info's destructor shouldn't be required to be virtual

Section: 18.7.1 [type.info] Status: Open Submitter: Stephan T. Lavavej Opened: 2014-06-14 Last modified: 2015-05-22

View all other issues in [type.info].

View all issues with Open status.

Discussion:

type_info's destructor is depicted as being virtual, which is nearly unobservable to users (since they can't construct or copy this class, they can't usefully derive from it). However, it's technically observable (via is_polymorphic and has_virtual_destructor). It also imposes real costs on implementations, requiring them to store one vptr per type_info object, when RTTI space consumption is a significant concern.

Making this implementation-defined wouldn't affect users (who can observe this only if they're specifically looking for it) and wouldn't affect implementations who need virtual here, but it would allow other implementations to drop virtual and improve their RTTI space consumption.

Richard Smith:

It's observable in a few other ways.

std::map<void*, something> m;
m[dynamic_cast<void*>(&typeid(blah))] = stuff;

... is broken by this change, because you can't dynamic_cast a non-polymorphic class type to void*.

type_info& f();
typeid(f());

... evaluates f() at runtime without this change, and might not do so with this change.

These are probably rare things, but I can imagine at least some forms of the latter being used in SFINAE tricks.

[Lenexa 2015-05-05: Move to Open]

Marshall to poll LEWG for their opinion

Proposed resolution:

This wording is relative to N3936.

  1. Change 18.7.1 [type.info] as indicated:

    namespace std {
      class type_info {
      public:
        virtualsee below ~type_info();
        […]
      };
    }
    

    -1- The class type_info describes type information generated by the implementation. Objects of this class effectively store a pointer to a name for the type, and an encoded value suitable for comparing two types for equality or collating order. The names, encoding rule, and collating sequence for types are all unspecified and may differ between programs. Whether ~type_info() is virtual is implementation-defined.


2402. basic_string(const basic_string& str, size_type pos, size_type n = npos) shouldn't use Allocator()

Section: 21.4.2 [string.cons] Status: Open Submitter: Stephan T. Lavavej Opened: 2014-06-14 Last modified: 2015-05-22

View all other issues in [string.cons].

View all issues with Open status.

Discussion:

21.4.2 [string.cons] p3 specifies:

basic_string(const basic_string& str, size_type pos, size_type n = npos, const Allocator& a = Allocator());

But this implies that basic_string(str, pos) and basic_string(str, pos, n) use Allocator() instead of getting an allocator from str.

21.4.1 [string.require] p3 says "The Allocator object used shall be obtained as described in 23.2.1." 23.2.1 [container.requirements.general] p8 says "Copy constructors for these container types obtain an allocator by calling allocator_traits<allocator_type>::select_on_container_copy_construction on the allocator belonging to the container being copied.", but this isn't exactly a copy constructor. Then it talks about move constructors (which this definitely isn't), and finally says that "All other constructors for these container types take a const allocator_type& argument. […] A copy of this allocator is used for any memory allocation performed".

[2015-05-06 Lenexa: move to Open]

STL: there an allocator right there in str, why default-construct one

STL: my fix, which may not be right, splits out functions with and without allocators

JW: there are other ways to propagate the allocator from str to the new object

PJP: hard to get motivated about this one

JW: I think this is not a copy operation, this is init'ing a string from a range of characters which happens to originate in a string. It makes it inconsistent with the similar ctor taking a const char pointer, and if we had a std::string_view we wouldn't even have this ctor, and it wouldn't be possible to propagate the allocator.

STL: but people with stateful allocators want it to propagate

JW: I think the people using stateful allocators will alter the default behaviour of select_on_container_copy_construction so that it doesn't propagate, but will return a default-constructed one (to ensure a stateful allocator referring to a stack buffer doesn't leak to a region where the stack buffer has gone). So for those people, your proposed change does nothing, it changes one default-constructed allocator to a call to select_on_container_copy_construction which returns a default-constructed allocator. For other people who have different stateful allocators they can still provide the right allocator (whatever that may be) by passing it in.

STL: OK, that's convincing.

PJP: I agree with Jonathan

JW: would like to run both our arguments by Pablo in case I'm totally misrepresenting the expected users of allocator-traits stuff

Proposed resolution:

This wording is relative to N3936.

  1. Change 21.4 [basic.string] p5, class template basic_string synopsis, as indicated:

    […]
    // 21.4.2, construct/copy/destroy:
    […]
    basic_string(basic_string&& str) noexcept;
    basic_string(const basic_string& str, size_type pos, size_type n = npos);
    basic_string(const basic_string& str, size_type pos, size_type n = npos,
                const Allocator& a = Allocator());
    […]
    
  2. Change 21.4.2 [string.cons] around p3 as indicated:

    basic_string(const basic_string& str, 
                 size_type pos, size_type n = npos);
    basic_string(const basic_string& str, 
                 size_type pos, size_type n = npos,
                 const Allocator& a = Allocator());
    

    […]

    -5- Effects: Constructs an object of class basic_string and determines the effective length rlen of the initial string value as the smaller of n and str.size() - pos, as indicated in Table 65. The first constructor obtains an allocator by calling allocator_traits<allocator_type>::select_on_container_copy_construction on the allocator belonging to str.

    Table 65 — basic_string(const basic_string&, size_type, size_type) and basic_string(const basic_string&, size_type, size_type, const Allocator&) effects


2413. assert macro is overconstrained

Section: 19.3 [assertions] Status: New Submitter: David Krauss Opened: 2014-06-25 Last modified: 2015-04-08

View other active issues in [assertions].

View all other issues in [assertions].

View all issues with New status.

Discussion:

When NDEBUG is defined, assert must expand exactly to the token sequence ((void)0), with no whitespace (C99 §7.2/1 and also C11 §7.2/1). This is a lost opportunity to pass the condition along to the optimizer.

The user may observe the token sequence using the stringize operator or discriminate it by making a matching #define directive. There is little chance of practical code doing such things. It's reasonable to allow any expansion that is a void expression with no side effects or semantic requirements, for example, an extension keyword or an attribute-specifier finagled into the context.

Conforming optimizations would still be limited to treating the condition as hint, not a requirement. Nonconformance on this point is quite reasonable though, given user preferences. Anyway, it shouldn't depend on preprocessor quirks.

As for current practice, Darwin OS <assert.h> provides a GCC-style compiler hint __builtin_expect but only in debug mode. Shouldn't release mode preserve hints?

Daniel:

The corresponding resolution should take care not to conflict with the intention behind LWG 2234.

Proposed resolution:


2414. Member function reentrancy should be implementation-defined

Section: 17.6.5.8 [reentrancy] Status: Open Submitter: Stephan T. Lavavej Opened: 2014-07-01 Last modified: 2015-05-05

View all other issues in [reentrancy].

View all issues with Open status.

Discussion:

N3936 17.6.5.8 [reentrancy]/1 talks about "functions", but that doesn't address the scenario of calling different member functions of a single object. Member functions often have to violate and then re-establish invariants. For example, vectors often have "holes" during insertion, and element constructors/destructors/etc. shouldn't be allowed to observe the vector while it's in this invariant-violating state. The [reentrancy] Standardese should be extended to cover member functions, so that implementers can either say that member function reentrancy is universally prohibited, or selectively allowed for very specific scenarios.

(For clarity, this issue has been split off from LWG 2382.)

[2014-11-03 Urbana]

AJM confirmed with SG1 that they had no special concerns with this issue, and LWG should retain ownership.

AM: this is too overly broad as it also covers calling the exact same member function on a different object
STL: so you insert into a map, and copying the value triggers another insertion into a different map of the same type
GR: reentrancy seems to imply the single-threaded case, but needs to consider the multi-threaded case

Needs more wording.

Move to Open

Proposed resolution:

This wording is relative to N3936.

  1. Change 17.6.5.8 [reentrancy] p1 as indicated:

    -1- Except where explicitly specified in this standard, it is implementation-defined which functions (including different member functions called on a single object) in the Standard C++ library may be recursively reentered.


2421. Non-specification of handling zero size in std::align [ptr.align]

Section: 20.7.5 [ptr.align] Status: New Submitter: Melissa Mears Opened: 2014-08-06 Last modified: 2015-04-08

View all other issues in [ptr.align].

View all issues with New status.

Discussion:

The specification of std::align does not appear to specify what happens when the value of the size parameter is 0. (The question of what happens when alignment is 0 is mentioned in another Defect Report, 2377; it would change the behavior to be undefined rather than potentially implementation-defined.)

The case of size being 0 is interesting because the result is ambiguous. Consider the following code's output:

#include <cstdio>
#include <memory>

int main()
{
  alignas(8) char buffer[8];
  void *ptr = &buffer[1];
  std::size_t space = sizeof(buffer) - sizeof(char[1]);

  void *result = std::align(8, 0, ptr, space);

  std::printf("%d %td\n", !!result, result ? (static_cast<char*>(result) - buffer) : std::ptrdiff_t(-1));
}

There are four straightforward answers as to what the behavior of std::align with size 0 should be:

  1. The behavior is undefined because the size is invalid.

  2. The behavior is implementation-defined. This seems to be the status quo, with current implementations using #3.

  3. Act the same as size == 1, except that if size == 1 would fail but would be defined and succeed if space were exactly 1 larger, the result is a pointer to the byte past the end of the ptr buffer. That is, the "aligned" version of a 0-byte object can be one past the end of an allocation. Such pointers are, of course, valid when not dereferenced (and a "0-byte object" shouldn't be), but whether that is desired is not specified in the Standard's definition of std::align, it appears. The output of the code sample is "1 8" in this case.

  4. Act the same as size == 1; this means that returning "one past the end" is not a possible result. In this case, the code sample's output is "0 -1".

The two compilers I could get working with std::align, Visual Studio 2013 and Clang 3.4, implement #3. (Change %td to %Id on Visual Studio 2013 and earlier. 2014 and later will have %td.)

Proposed resolution:


2422. std::numeric_limits<T>::is_modulo description: "most machines" errata

Section: 18.3.2.4 [numeric.limits.members] Status: Open Submitter: Melissa Mears Opened: 2014-08-06 Last modified: 2015-05-22

View all other issues in [numeric.limits.members].

View all issues with Open status.

Discussion:

The seemingly non-normative (?) paragraph 61 (referring to N3936) describing how "most machines" define std::numeric_limits<T>::is_modulo in [numeric.limits.members] appears to have some issues, in my opinion.

-61- On most machines, this is false for floating types, true for unsigned integers, and true for signed integers.

Issues I see:

  1. Very minor: change clause 2 to "this is false for floating point types". Other uses of the term say "floating point types" rather than just "floating types" — see nearby is_iec559, tinyness_before, etc.

  2. is_modulo must be true for unsigned integers in order to be compliant with the Standard; this is not just for "most machines". For reference, this requirement is from [basic.fundamental] paragraph 4 with its footnote 48.

  3. Depending on the definition of "most machines", is_modulo could be false for most machines' signed integer types. GCC, Clang and Visual Studio, the 3 most popular C++ compilers by far, by default treat signed integer overflow as undefined.

As an additional note regarding the definition of is_modulo, it seems like it should be explicitly mentioned that on an implementation for which signed integer overflow is undefined, is_modulo shall be false for signed integer types. It took bugs filed for all three of these compilers before they finally changed (or planned to change) is_modulo to false for signed types.

[2014-12 telecon]

HH: agree with the proposal, don't like the phrasing
AM: second note feels a bit wooly
WB: not even happy with the first note, notes shouldn't say "shall"
JW: the original isn't very prescriptive because "on most machines" is not something the standard controls.
AM: "On most machines" should become a note too?
AM: first note is repeating something defined in core, shouldn't say it normatively here. Change "shall" to "is"?
MC: don't like "signed integer overflow is left undefined" ... it's just plain undefined.
AM: implementations can define what they do in that case and provide guarantees.
WB: in paragraph 61, would like to see "this" replaced by "is_modulo"
AM: Move to Open

[2015-05-05 Lenexa]

Marshall: I will contact the submitter to see if she can re-draft the Proposed Resolution

Proposed resolution:

  1. Edit 18.3.2.4 [numeric.limits.members] around p60 as indicated:

    static constexpr bool is_modulo;
    

    -60- True if the type is modulo.(footnote) A type is modulo if, for any operation involving +, -, or * on values of that type whose result would fall outside the range [min(),max()], the value returned differs from the true value by an integer multiple of max() - min() + 1.

    -??- [Note: is_modulo shall be true for unsigned integer types (3.9.1 [basic.fundamental]). — end note]

    -??- [Note: is_modulo shall be false for types for which overflow is undefined on the implementation, because such types cannot meet the modulo requirement. Often, signed integer overflow is left undefined on implementations. — end note]

    -61- On most machines, this is false for floating point types, true for unsigned integers, and true for signed integers.

    -62- Meaningful for all specializations.


2423. Missing specification slice_array, gslice_array, mask_array, indirect_array copy constructor

Section: 26.6.5 [template.slice.array], 26.6.7 [template.gslice.array], 26.6.8 [template.mask.array], 26.6.9 [template.indirect.array] Status: New Submitter: Akira Takahashi Opened: 2014-08-12 Last modified: 2015-04-08

View all other issues in [template.slice.array].

View all issues with New status.

Discussion:

I found a missing specification of the copy constructor of the following class templates:

Proposed resolution:

  1. Before 26.6.5.2 [slice.arr.assign] insert a new sub-clause as indicated:

    -?- slice_array constructors [slice.arr.cons]

    slice_array(const slice_array&);
    

    -?- Effects: The constructed slice refers to the same valarray<T> object to which the argument slice refers.

  2. Before 26.6.7.2 [gslice.array.assign] insert a new sub-clause as indicated:

    -?- gslice_array constructors [gslice.array.cons]

    gslice_array(const gslice_array&);
    

    -?- Effects: The constructed slice refers to the same valarray<T> object to which the argument slice refers.

  3. Before 26.6.8.2 [mask.array.assign] insert a new sub-clause as indicated:

    -?- mask_array constructors [mask.array.cons]

    mask_array(const mask_array&);
    

    -?- Effects: The constructed slice refers to the same valarray<T> object to which the argument slice refers.

  4. Before 26.6.9.2 [indirect.array.assign] insert a new sub-clause as indicated:

    -?- indirect_array constructors [indirect.array.cons]

    indirect_array(const indirect_array&);
    

    -?- Effects: The constructed slice refers to the same valarray<T> object to which the argument slice refers.


2424. 29.5 should state that atomic types are not trivially copyable

Section: 29.5 [atomics.types.generic] Status: Review Submitter: Jens Maurer Opened: 2014-08-14 Last modified: 2015-05-22

View other active issues in [atomics.types.generic].

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

View all issues with Review status.

Discussion:

Otherwise, one could use memcpy to save and restore the value according to 3.9p2.

It seems the core language rules in 9 [class]p6 with 12.8 [class.copy]p12 (trivial copy constructor) etc. and 8.4.2 [dcl.fct.def.default]p5 (user-provided) say that the atomic types are trivially copyable, which is bad. We shouldn't rely on future core changes in that area and simply say in the library section 29.5 [atomics.types.generic] that these very special types are not trivially copyable.

[2014-11 Urbana]

Lawrence:Definition of "trivially copyable" has been changing.

Doesn't hurt to add proposed change, even if the sentence is redundant

Move to Review.

[2015-02 Cologne]

GR has a minor problem with the style of the wording. VV has major issues with implementability.

[2015-03-22, Jens Maurer responses to Cologne discussion]

A library implementation could provide a partial specialization for is_trivially_copyable<atomic<T>>, to ensure that any such type query would return false.

Assuming such a specialization would be provided, how could a conforming program observe that per language rules an atomic specialization would actually be trivially copyable if there is no way to call the (deleted) copy constructor or copy assignment operator?

The sole effect of the suggested addition of the constraining sentence is that it would make a user program non-conforming that attempts to invoke memcpy (and the like) on atomic types, since that would invoke undefined behaviour.

[2015-05 Lenexa, SG1 response]

SG1 is fine with P/R (and agrees it's needed), but LWG may want to check the details; it's not entirely an SG1 issue.

[2015-05-05 Lenexa]

Marshall: This was discussed on the telecon. Alisdair was going to write something to Mike and send it to Core.

Hwrd: Core says that deleted copies are trivially copyable, which makes no sense to Library people.

STL: There doesn't appear to be a Core issue about it.

Proposed resolution:

  1. Change 29.5 [atomics.types.generic]p3 as indicated:

    Specializations and instantiations of the atomic template shall have a deleted copy constructor, a deleted copy assignment operator, and a constexpr value constructor. They are not trivially copyable types (3.9 [basic.types]).


2426. Issue about compare_exchange

Section: 29.6.5 [atomics.types.operations.req] Status: Open Submitter: Hans Boehm Opened: 2014-08-25 Last modified: 2015-05-08

View other active issues in [atomics.types.operations.req].

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

View all issues with Open status.

Discussion:

The standard is either ambiguous or misleading about the nature of accesses through the expected argument to the compare_exchange_* functions in 29.6.5 [atomics.types.operations.req]p21.

It is unclear whether the access to expected is itself atomic (intent clearly no) and exactly when the implementation is allowed to read or write it. These affect the correctness of reasonable code.

Herb Sutter, summarizing a complaint from Duncan Forster wrote:

Thanks Duncan,

I think we have a bug in the standardese wording and the implementations are legal, but let's check with the designers of the feature.

Let me try to summarize the issue as I understand it:

  1. What I think was intended: Lawrence, I believe you championed having compare_exchange_* take the expected value by reference, and update expected on failure to expose the old value, but this was only for convenience to simplify the calling loops which would otherwise always have to write an extra "reload" line of code. Lawrence, did I summarize your intent correctly?

  2. What I think Duncan is trying to do: However, it turns out that, now that expected is an lvalue, it has misled(?) Duncan into trying to use the success of compare_exchange_* to hand off ownership of expected itself to another thread. For that to be safe, if the compare_exchange_* succeeds then the thread that performed it must no longer read or write from expected else his technique contains a race. Duncan, did I summarize your usage correctly? Is that the only use that is broken?

  3. What the standard says: I can see why Duncan thinks the standard supports his use, but I don't think this was intended (I don't remember this being discussed but I may have been away for that part) and unless you tell me this was intended I think it's a defect in the standard. From 29.6.5 [atomics.types.operations.req]/21:

    -21- Effects: Atomically, compares the contents of the memory pointed to by object or by this for equality with that in expected, and if true, replaces the contents of the memory pointed to by object or by this with that in desired, and if false, updates the contents of the memory in expected with the contents of the memory pointed to by object or by this. […]

    I think we have a wording defect here in any case, because the "atomically" should not apply to the entire sentence — I'm pretty sure we never intended the atomicity to cover the write to expected.

    As a case in point, borrowing from Duncan's mail below, I think the following implementation is intended to be legal:

    inline int _Compare_exchange_seq_cst_4(volatile _Uint4_t *_Tgt, _Uint4_t *_Exp, _Uint4_t _Value)
    { /* compare and exchange values atomically with
         sequentially consistent memory order */
      int _Res;
      _Uint4_t _Prev = _InterlockedCompareExchange((volatile long *)_Tgt, _Value, *_Exp);
      if (_Prev == *_Exp) //!!!!! Note the unconditional read from *_Exp here
        _Res = 1;
      else
      { /* copy old value */
        _Res = 0;
        *_Exp = _Prev;
      }
      return (_Res);
    }
    

    I think this implementation is intended to be valid — I think the only code that could be broken with the "!!!!!" read of *_Exp is Duncan's use of treating a.compare_exchange_*(expected, desired) == true as implying expected got handed off, because then another thread could validly be using *_Exp — but we never intended this use, right?

In a different thread Richard Smith wrote about the same problem:

The atomic_compare_exchange functions are described as follows:

"Atomically, compares the contents of the memory pointed to by object or by this for equality with that in expected, and if true, replaces the contents of the memory pointed to by object or by this with that in desired, and if false, updates the contents of the memory in expected with the contents of the memory pointed to by object or by this. Further, if the comparison is true, memory is affected according to the value of success, and if the comparison is false, memory is affected according to the value of failure."

I think this is less clear than it could be about the effects of these operations on *expected in the failure case:

  1. We have "Atomically, compares […] and updates the contents of the memory in expected […]". The update to the memory in expected is clearly not atomic, and yet this wording parallels the success case, in which the memory update is atomic.

  2. The wording suggests that memory (including *expected) is affected according to the value of failure. In particular, the failure order could be memory_order_seq_cst, which might lead someone to incorrectly think they'd published the value of *expected.

I think this can be clarified with no change in meaning by reordering the wording a little:

"Atomically, compares the contents of the memory pointed to by object or by this for equality with that in expected, and if true, replaces the contents of the memory pointed to by object or by this with that in desired, and if. If the comparison is true, memory is affected according to the value of success, and if the comparison is false, memory is affected according to the value of failure. Further, if the comparison is false, updatesreplaces the contents of the memory in expected with the contents ofvalue that was atomically read from the memory pointed to by object or by this. Further, if the comparison is true, memory is affected according to the value of success, and if the comparison is false, memory is affected according to the value of failure."

Jens Maurer add:

I believe this is an improvement.

I like to see the following additional improvements:

There was also a discussion thread involving Herb Sutter, Hans Boehm, and Lawrence Crowl, resulting in proposed wording along the lines of:

-21- Effects: Atomically with respect to expected and the memory pointed to by object or by this, compares the contents of the memory pointed to by object or by this for equality with that in expected, and if and only if true, replaces the contents of the memory pointed to by object or by this with that in desired, and if and only if false, updates the contents of the memory in expected with the contents of the memory pointed to by object or by this.

At the end of paragraph 23, perhaps add

[Example: Because the expected value is updated only on failure, code releasing the memory containing the expected value on success will work. E.g. list head insertion will act atomically and not have a data race in the following code.

do {
  p->next = head; // make new list node point to the current head
} while(!head.compare_exchange_weak(p->next, p)); // try to insert

end example]

Hans objected that this still gives the misimpression that the update to expected is atomic.

[2014-11 Urbana]

Proposed resolution was added after Redmond.

Recommendations from SG1:

  1. Change wording to if trueif and only if true, and change if falseif and only if false.
  2. If they want to add "respect to" clause, say "respect to object or this".
  3. In example, load from head should be "head.load(memory_order_relaxed)", because people are going to use example as example of good code.

(wording edits not yet applied)

[2015-02 Cologne]

Handed over to SG1.

[2015-05 Lenexa, SG1 response]

We believed we were done with it, but it was kicked back to us, with the wording we suggested not yet applied. It may have been that our suggestions were unclear. Was that the concern?

Proposed resolution:

  1. Edit 29.6.5 [atomics.types.operations.req] p21 as indicated:

    -21- Effects: Retrieves the value in expected. It then aAtomically, compares the contents of the memory pointed to by object or by this for equality with that inpreviously retrieved from expected, and if true, replaces the contents of the memory pointed to by object or by this with that in desired, and if false, updates the contents of the memory in expected with the contents of the memory pointed to by object or by this. Further, if. If and only if the comparison is true, memory is affected according to the value of success, and if the comparison is false, memory is affected according to the value of failure. When only one memory_order argument is supplied, the value of success is order, and the value of failure is order except that a value of memory_order_acq_rel shall be replaced by the value memory_order_acquire and a value of memory_order_release shall be replaced by the value memory_order_relaxed. If the comparison is false then, after the atomic operation, the contents of the memory in expected are replaced by the value read from object or by this during the atomic comparison. If the operation returns true, these operations are atomic read-modify-write operations (1.10) on the memory pointed to by this or object. Otherwise, these operations are atomic load operations on that memory.

  2. Add the following example to the end of 29.6.5 [atomics.types.operations.req] p23:

    -23- [Note: […] — end note] [Example: […] — end example]

    [Example: Because the expected value is updated only on failure, code releasing the memory containing the expected value on success will work. E.g. list head insertion will act atomically and would not introduce a data race in the following code:

    
    do {
      p-i>next = head; // make new list node point to the current head
    } while(!head.compare_exchange_weak(p->next, p)); // try to insert
    

    end example]


2431. Missing regular expression traits requirements

Section: 28.3 [re.req] Status: New Submitter: Jonathan Wakely Opened: 2014-09-30 Last modified: 2015-04-08

View all issues with New status.

Discussion:

The requirements on the traits class in 28.3 [re.req] do not say whether a regular expression traits class is required to be DefaultConstructible, CopyConstructible, CopyAssignable etc.

The std::regex_traits class appears to be all of the above, but can basic_regex assume that for user-defined traits classes?

Should the following statements all leave u in equivalent states?

X u{v};
X u; u = v;
X u; u.imbue(v.getloc();

Whether they are equivalent has implications for basic_regex copy construction and assignment.

Proposed resolution:


2432. initializer_list assignability

Section: 18.9 [support.initlist] Status: EWG Submitter: David Krauss Opened: 2014-09-30 Last modified: 2015-05-22

View other active issues in [support.initlist].

View all other issues in [support.initlist].

View all issues with EWG status.

Discussion:

std::initializer_list::operator= 18.9 [support.initlist] is horribly broken and it needs deprecation:

std::initializer_list<foo> a = {{1}, {2}, {3}};
a = {{4}, {5}, {6}};
// New sequence is already destroyed.

Assignability of initializer_list isn't explicitly specified, but most implementations supply a default assignment operator. I'm not sure what 17.5 [description] says, but it probably doesn't matter.

[Lenexa 2015-05-05: Send to EWG as discussed in Telecon]

Proposed resolution:

  1. Edit 18.9 [support.initlist] p1, class template initializer_list synopsis, as indicated:

    namespace std {
      template<class E> class initializer_list {
      public:
        […]
        constexpr initializer_list() noexcept;
      
        initializer_list(const initializer_list&) = default;
        initializer_list(initializer_list&&) = default;
        initializer_list& operator=(const initializer_list&) = delete;
        initializer_list& operator=(initializer_list&&) = delete;
        
        constexpr size_t size() const noexcept;
        […]
      };
      […]
    }
    

2441. Exact-width atomic typedefs should be provided

Section: 29.5 [atomics.types.generic] Status: Open Submitter: Stephan T. Lavavej Opened: 2014-10-01 Last modified: 2015-05-08

View other active issues in [atomics.types.generic].

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

View all issues with Open status.

Discussion:

<atomic> doesn't provide counterparts for <inttypes.h>'s most useful typedefs, possibly because they're quasi-optional. We can easily fix this.

[2014-11, Urbana]

Typedefs were transitional compatibility hack. Should use _Atomic macro or template. E.g. _Atomic(int8_t). BUT _Atomic disappeared!

Detlef will look for _Atomic macro. If missing, will open issue.

[2014-11-25, Hans comments]

There is no _Atomic in C++. This is related to the much more general unanswered question of whether C++17 should reference C11, C99, or neither.

[2015-02 Cologne]

AM: I think this is still an SG1 issue; they need to deal with it before we do.

[2015-05 Lenexa, SG1 response]

Move to SG1-OK status. This seems like an easy short-term fix. We probably need a paper on C/C++ atomics compatibility to deal with _Atomic, but that's a separable issue.

Proposed resolution:

This wording is relative to N3936.

  1. Change 29.5 [atomics.types.generic] p8 as depicted:

    -8- There shall be atomic typedefs corresponding to the typedefs in the header <inttypes.h> as specified in Table 147. atomic_intN_t, atomic_uintN_t, atomic_intptr_t, and atomic_uintptr_t shall be defined if and only if intN_t, uintN_t, intptr_t, and uintptr_t are defined, respectively.

  2. Change 29.6.5 [atomics.types.operations.req], Table 147 ("atomic <inttypes.h> typedefs"), as depicted:

    Table 147 — atomic <inttypes.h> typedefs
    Atomic typedef <inttypes.h> type
    atomic_int8_t int8_t
    atomic_uint8_t uint8_t
    atomic_int16_t int16_t
    atomic_uint16_t uint16_t
    atomic_int32_t int32_t
    atomic_uint32_t uint32_t
    atomic_int64_t int64_t
    atomic_uint64_t uint64_t

2444. Inconsistent complexity for std::sort_heap

Section: 25.4.6.4 [sort.heap] Status: Open Submitter: François Dumont Opened: 2014-10-07 Last modified: 2015-05-22

View all issues with Open status.

Discussion:

While creating complexity tests for the GNU libstdc++ implementation I stumbled across a surprising requirement for the std::sort_heap algorithm.

In 25.4.6.4 [sort.heap] p3 the Standard states:

Complexity: At most N log(N) comparisons (where N == last - first).

As stated on the libstdc++ mailing list by Marc Glisse sort_heap can be implemented by N calls to pop_heap. As max number of comparisons of pop_heap is 2 * log(N) then sort_heap max limit should be 2 * log(1) + 2 * log(2) + .... + 2 * log(N) that is to say 2 * log(N!). In terms of log(N) we can also consider that this limit is also cap by 2 * N * log(N) which is surely what the Standard wanted to set as a limit.

This is why I would like to propose to replace paragraph 3 by:

Complexity: At most 2N log(N) comparisons (where N == last - first).

[2015-02 Cologne]

Marshall will research the maths and report back in Lenexa.

[2015-05-06 Lenexa]

STL: I dislike exact complexity requirements, they prevent one or two extra checks in debug mode. Would it be better to say O(N log(N)) not at most?

Proposed resolution:

This wording is relative to N3936.

  1. In 25.4.6.4 [sort.heap] p3 the Standard states:

    template<class RandomAccessIterator>
      void sort_heap(RandomAccessIterator first, RandomAccessIterator last);
    template<class RandomAccessIterator, class Compare>
      void sort_heap(RandomAccessIterator first, RandomAccessIterator last,
                     Compare comp);
    

    […]

    -3- Complexity: At most 2N log(N) comparisons (where N == last - first).


2449. vector::insert invalidates end()?

Section: 23.3.6.5 [vector.modifiers] Status: New Submitter: Marc Glisse Opened: 2014-10-21 Last modified: 2015-04-08

View other active issues in [vector.modifiers].

View all other issues in [vector.modifiers].

View all issues with New status.

Discussion:

this issue is based on the discussion here.

23.3.6.5 [vector.modifiers] says about vector::insert: "If no reallocation happens, all the iterators and references before the insertion point remain valid." This doesn't seem to guarantee anything about the iterator at the point of insertion.

The question comes from people asking if the following is valid, assuming a sufficient call to reserve() was done first:

v.insert(v.end(), v.begin(), v.end());

It could fail for an implementation using a sentinel for the end of the vector, but I don't know of any (it would be quite inconvenient). And for any implementation using a simple position as iterator (pointer (possibly in a wrapper), or base+offset), this is needlessly restrictive. The fact that this alternative:

v.insert(v.end(), &v[0], &v[0]+v.size())

is arguably valid (again assuming a large enough reserve()) makes it a bit confusing that the first version isn't (23.2.3 [sequence.reqmts] has a precondition that iterator arguments to insert() do not point into the sequence, but vector::insert is more refined and seems to give enough guarantees that it cannot fail).

Then we might as well say that vector iterators act as positions, and that after a reallocation-free operation an iterator points to the same position, whatever may be there now…

Proposed resolution:


2450. (greater|less|greater_equal|less_equal)<void> do not yield a total order for pointers

Section: 20.9.6 [comparisons] Status: Open Submitter: Joaquín M López Muñoz Opened: 2014-10-30 Last modified: 2015-05-06

View other active issues in [comparisons].

View all other issues in [comparisons].

View all issues with Open status.

Discussion:

less<void>::operator(t, u) (and the same applies to the rest of void specializations for standard comparison function objects) returns t < u even if t and u are pointers, which by 5.9 [expr.rel]/3 is undefined except if both pointers point to the same array or object. This might be regarded as a specification defect since the intention of N3421 is that less<> can substitute for less<T> in any case where the latter is applicable. less<void> can be rewritten in the following manner to cope with pointers:

template<> struct less<void>
{

  typedef unspecified is_transparent;

  template <class T, class U>
  struct pointer_overload : std::is_pointer<std::common_type_t<T, U>>
  {};

  template <
    class T, class U,
    typename std::enable_if<!pointer_overload<T, U>::value>::type* = nullptr
  >
  auto operator()(T&& t, U&& u) const
    -> decltype(std::forward<T>(t) < std::forward<U>(u))
  {
    return std::forward<T>(t) < std::forward<U>(u);
  } 

  template <
    class T, class U,
    typename std::enable_if<pointer_overload<T, U>::value>::type* = nullptr
  >
  auto operator()(T&& t, U&& u) const
    -> decltype(std::declval<std::less<std::common_type_t<T, U>>>()(std::forward<T>(t), std::forward<U>(u)))
  {
    std::less<std::common_type_t<T, U>> l;
    return l(std::forward<T>(t), std::forward<U>(u));
  }

};

This wording is relative to N4140.

  1. Change 20.9.6 [comparisons] p14 as indicated:

    -14- For templates greater, less, greater_equal, and less_equal, the specializations for any pointer type yield a total order, even if the built-in operators <, >, <=, >= do not. For template specializations greater<void>, less<void>, greater_equal<void>, and less_equal<void>, the call operator with arguments whose common type CT is a pointer yields the same value as the corresponding comparison function object class specialization for CT.

[2015-02, Cologne]

AM: Is there any way this will be resolved elsewhere? VV: No. AM: Then we should bite the bullet and deal with it here.

MC: These diamond operators are already ugly. Making them more ugly isn't a big problem.

JY found some issue with types that are convertible, and will reword.

Jeffrey suggests improved wording.

[2015-05, Lenexa]

STL: when diamond functions designed, this was on purpose
STL: this does go against the original design
STL: library is smarter and can give a total order
MC: given that the original design rejected this, give back to LEWG
STL: original proposal did not talk about total order
STL: don't feel strongly about changing the design
STL: no objections to taking this issue with some wording changes if people want it
MC: not happy with wording, comparing pointers — what does that mean?
STL: needs careful attention to wording
STL: want to guarantee that nullptr participates in total ordering
STL: all hooks into composite pointer type
MC: move from new to open with better wording
STL: to check updates to issue after Lenexa

Proposed resolution:

This wording is relative to N4296.

  1. Change 20.9.6 [comparisons] p14 as indicated:

    -14- For templates greater, less, greater_equal, and less_equal, the specializations for any pointer type yield a total order, even if the built-in operators <, >, <=, >= do not. For template specializations greater<void>, less<void>, greater_equal<void>, and less_equal<void>, if the call operator calls a built-in operator comparing pointers, the call operator yields a total order.


2452. is_constructible, etc. and default arguments

Section: 20.10 [meta] Status: Core Submitter: Hubert Tong Opened: 2014-11-04 Last modified: 2015-04-08

View other active issues in [meta].

View all other issues in [meta].

View all issues with Core status.

Discussion:

The BaseCharacteristic for is_constructible is defined in terms of the well-formedness of a declaration for an invented variable. The well-formedness of the described declaration itself may change for the same set of arguments because of the introduction of default arguments.

In the following program, there appears to be conflicting definitions of a specialization of std::is_constructible; however, it seems that this situation is caused without a user violation of the library requirements or the ODR. There is a similar issue with is_convertible, result_of and others.

a.cc:

#include <type_traits>
struct A { A(int, int); };
const std::false_type& x1 = std::is_constructible<A, int>();

int main() { }

b.cc:

#include <type_traits>
struct A { A(int, int); };

inline A::A(int, int = 0) { }

const std::true_type& x2 = std::is_constructible<A, int>();

Presumably this program should invoke undefined behaviour, but the Library specification doesn't say that.

[2015-02 Cologne]

Core wording should say "this kind of thing is ill-formed, no diagnostic required"

Proposed resolution:


2453. [iterator.range] and now [iterator.container] aren't available via <initializer_list>

Section: 18.9 [support.initlist], 24.7 [iterator.range], 24.8 [iterator.container] Status: New Submitter: Richard Smith Opened: 2014-11-11 Last modified: 2015-04-08

View other active issues in [support.initlist].

View all other issues in [support.initlist].

View all issues with New status.

Discussion:

These sections define helper functions, some of which apply to initializer_list<T>. And they're available if you include one of a long list of header files, many of which include <initializer_list>. But they are not available if you include <initializer_list>. This seems very odd.

#include <initializer_list>
auto x = {1, 2, 3};
const int *p = data(x); // error, undeclared
#include <vector>
const int *q = data(x); // ok

Proposed resolution:


2456. Incorrect exception specifications for 'swap' throughout library

Section: 20.2 [utility], 20.3.2 [pairs.pair], 20.4 [tuple], 23.3.2 [array], 23.6.3 [queue], 23.6.4 [priority.queue], 23.6.5 [stack] Status: Open Submitter: Richard Smith Opened: 2014-11-14 Last modified: 2015-05-05

View other active issues in [utility].

View all other issues in [utility].

View all issues with Open status.

Discussion:

We have this antipattern in various library classes:

void swap(priority_queue& q) noexcept(
    noexcept(swap(c, q.c)) && noexcept(swap(comp, q.comp)))

This doesn't work. The unqualified lookup for 'swap' finds the member named 'swap', and that suppresses ADL, so the exception specification is always ill-formed because you can't call the member 'swap' with two arguments.

Relevant history on the core language side:

This used to be ill-formed due to 3.3.7 [basic.scope.class] p1 rule 2: "A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule."

Core issue 1330 introduced delay-parsing for exception specifications. Due to the 3.3.7 [basic.scope.class] rules, this shouldn't have changed the behavior of any conforming programs. But it changes the behavior in the non-conforming case from "no diagnostic required" to "diagnostic required", so implementations that implement core issue 1330 are now required to diagnose the ill-formed declarations in the standard library.

Suggested resolution:

Add an is_nothrow_swappable trait, and use it throughout the library in place of these noexcept expressions.

[2015-02, Cologne]

No action for now; we intend to have papers for Lenexa.

[2015-05, Lenexa]

Move to Open.

Daniel: A first paper (N4426) exists to suggest some ways of solving this issue.

Proposed resolution:


2457. std::begin() and std::end() do not support multi-dimensional arrays correctly

Section: 24.7 [iterator.range] Status: New Submitter: Janez Žemva Opened: 2014-11-16 Last modified: 2015-04-08

View other active issues in [iterator.range].

View all other issues in [iterator.range].

View all issues with New status.

Discussion:

The following code:

#include <algorithm>
#include <iterator>
#include <iostream>
#include <cassert>

int main() 
{
  int a[2][3][4] = { { { 1,  2,  3,  4}, { 5,  6,  7,  8}, { 9, 10, 11, 12} },
                     { {13, 14, 15, 16}, {17, 18, 19, 20}, {21, 22, 23, 24} } };
  int b[2][3][4];

  assert(std::distance(std::begin(a), std::end(a)) == 2 * 3 * 4);
  std::copy(std::begin(a), std::end(a), std::begin(b));
  std::copy(std::begin(b), std::end(b), std::ostream_iterator<int>(std::cout, ","));
}

does not compile.

A possible way to remedy this would be to add the following overloads of begin, end, rbegin, and rend to 24.7 [iterator.range], relying on recursive evaluation:

namespace std {

  template <typename T, size_t M, size_t N>
  constexpr remove_all_extents_t<T>*
  begin(T (&array)[M][N])
  {
    return begin(*array);
  }
  
  template <typename T, size_t M, size_t N>
  constexpr remove_all_extents_t<T>*
  end(T (&array)[M][N])
  {
    return end(array[M - 1]);
  }

  template <typename T, size_t M, size_t N>
  reverse_iterator<remove_all_extents_t<T>*>
  rbegin(T (&array)[M][N])
  {
    return decltype(rbegin(array))(end(array[M - 1]));
  }
  
  template <typename T, size_t M, size_t N>
  reverse_iterator<remove_all_extents_t<T>*>
  rend(T (&array)[M][N])
  {
    return decltype(rend(array))(begin(*array));
  }

}

Proposed resolution:


2460. LWG issue 2408 and value categories

Section: 20.10.7.6 [meta.trans.other], 24.4.1 [iterator.traits] Status: New Submitter: Richard Smith Opened: 2014-11-19 Last modified: 2015-04-08

View other active issues in [meta.trans.other].

View all other issues in [meta.trans.other].

View all issues with New status.

Discussion:

LWG issue 2408 changes the meat of the specification of common_type to compute:

[..] the type, if any, of an unevaluated conditional expression (5.16) whose first operand is an arbitrary value of type bool, whose second operand is an xvalue of type T1, and whose third operand is an xvalue of type T2.

This has an effect on the specification that I think was unintended. It used to be the case that common_type<T&, U&&> would consider the type of a conditional between an lvalue of type T and an xvalue of type U. It's now either invalid (because there is no such thing as an xvalue of reference type) or considers the type of a conditional between an xvalue of type T and an xvalue of type U, depending on how you choose to read it.

Put another way, this has the effect of changing the usual definition from:

typedef decay_t<decltype(true ? declval<T>() : declval<U>())> type;

to:

typedef decay_t<decltype(true ? declval<remove_reference_t<T>>() : declval<remove_reference_t<U>>())> type;

It also makes common_type underspecified in the case where one of the operands is of type void; in that case, the resulting type depends on whether the expression is a throw-expression, which is not specified (but used to be).

Also on the subject of this wording: the changes to 24.4.1 [iterator.traits] say that iterator_traits<T> "shall have no members" in some cases. That's wrong. It's a class type; it always has at least a copy constructor, a copy assignment operator, and a destructor. Plus this removes the usual library liberty to add additional members with names that don't collide with normal usage (for instance, if a later version of the standard adds members, they can't be present here as a conforming extension). Perhaps this should instead require that the class doesn't have members with any of those five names? That's what 2408 does for common_type's type member.

Proposed resolution:


2461. Interaction between allocators and container exception safety guarantees

Section: 17.6.3.5 [allocator.requirements], 23.3.6.3 [vector.capacity], 23.3.6.5 [vector.modifiers] Status: New Submitter: dyp Opened: 2014-12-06 Last modified: 2015-04-08

View other active issues in [allocator.requirements].

View all other issues in [allocator.requirements].

View all issues with New status.

Discussion:

When resizing a vector, the accessibility and exception specification of the value type's constructors determines whether the elements are copied or moved to the new buffer. However, the copy/move is performed via the allocator's construct member function, which is assumed, but not required, to call the copy/move constructor and propagate only exceptions from the value type's copy/move constructor. The issue might also affect other classes.

The current wording in N4296 relevant here is from Table 28 — "Allocator requirements" in 17.6.3.5 [allocator.requirements]:

Table 28 — Allocator requirements
Expression Return type Assertion/note
pre-/post-condition
Default
a.construct(c, args) (not used) Effect: Constructs an object of type C at c ::new ((void*)c) C(forward<Args>(args)...)

and from 17.6.3.5 [allocator.requirements] p9:

An allocator may constrain the types on which it can be instantiated and the arguments for which its construct member may be called. If a type cannot be used with a particular allocator, the allocator class or the call to construct may fail to instantiate.

I conclude the following from the wording:

  1. The allocator is not required to call the copy constructor if the arguments (args) is a single (potentially const) lvalue of the value type. Similarly for a non-const rvalue + move constructor. See also 23.2.1 [container.requirements.general] p15 which seems to try to require this, but is not sufficient: That paragraph specifies the semantics of the allocator's operations, but not which constructors of the value type are used, if any.

  2. The allocator may throw exceptions in addition to the exceptions propagated by the constructors of the value type; it can also propagate exceptions from constructors other than a copy/move constructor.

This leads to an issue with the wording of the exception safety guarantees for vector modifiers in 23.3.6.5 [vector.modifiers] p1:

[…]

void push_back(const T& x);
void push_back(T&& x);

Remarks: Causes reallocation if the new size is greater than the old capacity. If no reallocation happens, all the iterators and references before the insertion point remain valid. If an exception is thrown other than by the copy constructor, move constructor, assignment operator, or move assignment operator of T or by any InputIterator operation there are no effects. If an exception is thrown while inserting a single element at the end and T is CopyInsertable or is_nothrow_move_constructible<T>::value is true, there are no effects. Otherwise, if an exception is thrown by the move constructor of a non-CopyInsertable T, the effects are unspecified.

The wording leads to the following problem: Copy and move assignment are invoked directly from vector. For intermediary objects (see 2164), vector also directly invokes the copy and move constructor of the value type. However, construction of the actual element within the buffer is invoked via the allocator abstraction. As discussed above, the allocator currently is not required to call a copy/move constructor. If is_nothrow_move_constructible<T>::value is true for some value type T, but the allocator uses modifying operations for MoveInsertion that do throw, the implementation is required to ensure that "there are no effects", even if the source buffer has been modified.

Similarly, the vector capacity functions specify exception safety guarantees referring to the move constructor of the value type. For example, vector::resize in 23.3.6.3 [vector.capacity] p14:

Remarks: If an exception is thrown other than by the move constructor of a non-CopyInsertable T there are no effects.

The wording leads to the same issue as described above.

Code example:

template<class T>
class allocator;

class pot_reg_type // a type which creates
                   // potentially registered instances
{
private:
  friend class allocator<pot_reg_type>;
  struct register_t {};

  static std::set<pot_reg_type*>& get_registry()
  {
    static std::set<pot_reg_type*> registry;
    return registry;
  }
  void enregister() noexcept(false)
  {
    get_registry().insert(this);
  }
  void deregister()
  {
    get_registry().erase(this);
  }

public:
  pot_reg_type(void               ) noexcept(true) {}
  pot_reg_type(pot_reg_type const&) noexcept(true) {}
  pot_reg_type(pot_reg_type&&     ) noexcept(true) {}

private:
  pot_reg_type(register_t                     ) noexcept(false)
  { enregister(); }
  pot_reg_type(register_t, pot_reg_type const&) noexcept(false)
  { enregister(); }
  pot_reg_type(register_t, pot_reg_type&&     ) noexcept(false)
  { enregister(); }
};

template<class T>
class allocator
{
public:
  using value_type = T;

  value_type* allocate(std::size_t p)
  { return (value_type*) ::operator new(p); }

  void deallocate(value_type* p, std::size_t)
  { ::operator delete(p); }

  void construct(pot_reg_type* pos)
  {
    new((void*)pos) pot_reg_type((pot_reg_type::register_t()));
  }
  void construct(pot_reg_type* pos, pot_reg_type const& source)
  {
    new((void*)pos) pot_reg_type(pot_reg_type::register_t(), source);
  }

  template<class... Args>
  void construct(T* p, Args&&... args)
  {
    new((void*)p) T(std::forward<Args>(args)...);
  }
}; 

The construct member function template is only required for rebinding, which can be required e.g. to store additional debug information in the allocated memory (e.g. VS2013).

Even though the value type has an accessible and noexcept(true) move constructor, this allocator won't call that constructor for rvalue arguments. In any case, it does not call a constructor for which vector has formulated its requirements. An exception thrown by a constructor called by this allocator is not covered by the specification in 23.3.6.5 [vector.modifiers] and therefore is guaranteed not to have any effect on the vector object when resizing.

For an example how this might invalidate the exception safety guarantees, see this post on the std-discussion mailing list.

Another problem arises for value types whose constructors are private, but may be called by the allocator e.g. via friendship. Those value types are not MoveConstructible (is_move_constructible is false), yet they can be MoveInsertable. It is not possible for vector to create intermediary objects (see 2164) of such a type by directly using the move constructor. Current implementations of the single-element forms of vector::insert and vector::emplace do create intermediary objects by directly calling one of the value type's constructors, probably to allow inserting objects from references that alias other elements of the container. As far as I can see, Table 100 — "Sequence container requirements" in 23.2.3 [sequence.reqmts] does not require that the creation of such intermediare objects can be performed by containers using the value type's constructor directly. It is unclear to me if the allocator's construct function could be used to create those intermediary objects, given that they have not been allocated by the allocator.

Two possible solutions:

  1. Add the following requirement to the allocator_traits::construct function: If the parameter pack args consists of a single parameter of the type value_type&&, the function may only propagate exceptions if is_nothrow_move_constructible<value_type>::value is false.

    Requiring alloctor_traits::construct to call a true copy/move constructor of the value type breaks std::scoped_allocator_adapter, as pointed out by Casey Carter in a post on the std-discussion mailing list.

  2. Change vector's criterion whether to move or copy when resizing:

    Instead of testing the value type's constructors via is_move_constructible, check the value of noexcept( allocator_traits<Allocator>::construct(alloc, ptr, rval) ) where alloc is an lvalue of type Allocator, ptr is an expression of type allocator_traits<Allocator>::pointer and rval is a non-const rvalue of type value_type.

A short discussion of the two solutions:

Solution 1 allows keeping is_nothrow_move_constructible<value_type> as the criterion for vector to decide between copying and moving when resizing. It restricts what can be done inside the construct member function of allocators, and requires implementers of allocators to pay attention to the value types used. One could conceive allocators checking the following with a static_assert: If the value type is_nothrow_move_constructible, then the constructor actually called for MoveInsertion within the construct member function is also declared as noexcept.

Solution 2 requires changing both the implementation of the default allocator (add a conditional noexcept) and vector (replace is_move_constructible with an allocator-targeted check). It does not impose additional restrictions on the allocator (other than 23.2.1 [container.requirements.general] p15), and works nicely even if the move constructor of a MoveInsertable type is private or deleted (the allocator might be a friend of the value type).

In both cases, an addition might be required to provide the basic exception safety guarantee. A short discussion on this topic can be found in the std-discussion mailing list. Essentially, if allocator_traits<Allocator>::construct throws an exception, the object may or may not have been constructed. Two solutions are mentioned in that discussion:

  1. allocator_traits<Allocator>::construct needs to tell its caller whether or not the construction was successful, in case of an exception.

  2. If allocator_traits<Allocator>::construct propagates an exception, it shall either not have constructed an object at the specified location, or that object shall have been destroyed (or it shall ensure otherwise that no resources are leaked).

Proposed resolution:


2465. SFINAE-friendly common_type is nearly impossible to specialize correctly and regresses key functionality

Section: 20.10.7.6 [meta.trans.other] Status: New Submitter: Eric Niebler Opened: 2015-01-12 Last modified: 2015-04-08

View other active issues in [meta.trans.other].

View all other issues in [meta.trans.other].

View all issues with New status.

Discussion:

I think there's a defect regarding common_type and its specializations. Unless I've missed it, there is nothing preventing folks from instantiating common_type with cv-qualified types or reference types. In fact, the wording in N3797 explicitly mentions cv void, so presumably at least cv qualifications are allowed.

Users are given license to specialize common_type when at least of of the types is user-defined. (A separate issue is the meaning of user-defined. In core, I believe this is any class/struct/union/enum, but in lib, I think it means any type not defined in std, right?) There is at least one place in the standard that specializes common_type (time.traits.specializations) on time_point and duration. But the specializations are only for non-cv-qualified and non-reference specializations of time_point and duration.

If the user uses, say, common_type<duration<X,Y> const, duration<A,B> const>, they're not going to get the behavior they expect.

Suggest we clarify the requirements of common_type's template parameters. Also, perhaps we can add blanket wording that common_type<A [cv][&], B [cv][&]> is required to be equivalent to common_type<A,B> (if that is in fact the way we intent this to work).

Also, the change to make common_type SFINAE-friendly regressed key functionality, as noted by Agustín K-ballo Bergé in c++std-lib-37178. Since decay_t is not applied until the very end of the type computation, user specializations are very likely to to be found.

Agustín says:

Consider the following snippet:

struct X {};
struct Y { explicit Y(X){} };

namespace std {
  template<> struct common_type<X, Y> { typedef Y type; };
  template<> struct common_type<Y, X> { typedef Y type; };
}

static_assert(is_same<common_type_t<X, Y>, Y>()); // (A)
static_assert(is_same<common_type_t<X, Y, Y>, Y>()); // (B)
static_assert(is_same<common_type_t<X, X, Y>, Y>()); // (C)

Under the original wording, all three assertion holds. Under the current wording,

The discussion following c++std-lib-35636 seemed to cohere around the idea that the primary common_type specialization should have the effect of stripping top-level ref and cv qualifiers by applying std::decay_t to its arguments and, if any of them change as a result of that transformation, re-dispatching to common_type on those transformed arguments, thereby picking up any user-defined specializations. This change to common_type would make the specializations in time.traits.specializations sufficient.

Suggested wording:

I'm afraid I don't know enough to suggest wording. But for exposition, the following is my best shot at implementing the suggested resolution. I believe it also fixes the regression noted by Agustín K-ballo Bergé in c++std-lib-37178.

namespace detail
{
    template<typename T, typename U>
    using default_common_t =
        decltype(true? std::declval<T>() : std::declval<U>());

    template<typename T, typename U, typename Enable = void>
    struct common_type_if
    {};

    template<typename T, typename U>
    struct common_type_if<T, U,
      void_t<default_common_t<T, U>>>
    {
      using type = decay_t<default_common_t<T, U>>;
    };

    template<typename T, typename U,
       typename TT = decay_t<T>, typename UU = decay_t<U>>
    struct common_type2
      : common_type<TT, UU> // Recurse to catch user specializations
    {};

    template<typename T, typename U>
    struct common_type2<T, U, T, U>
      : common_type_if<T, U>
    {};

    template<typename Meta, typename Enable = void>
    struct has_type
      : std::false_type
    {};

    template<typename Meta>
    struct has_type<Meta, void_t<typename Meta::type>>
      : std::true_type
    {};

    template<typename Meta, typename...Ts>
    struct common_type_recurse
      : common_type<typename Meta::type, Ts...>
    {};

    template<typename Meta, typename...Ts>
    struct common_type_recurse_if
      : std::conditional<
          has_type<Meta>::value,
          common_type_recurse<Meta, Ts...>,
          empty
        >::type
    {};
}

template<typename ...Ts>
struct common_type
{};

template<typename T>
struct common_type<T>
{
  using type = std::decay_t<T>;
};

template<typename T, typename U>
struct common_type<T, U>
  : detail::common_type2<T, U>
{};

template<typename T, typename U, typename... Vs>
struct common_type<T, U, Vs...>
  : detail::common_type_recurse_if<common_type<T, U>, Vs...>
{};

Proposed resolution:


2468. Self-move-assignment of library types

Section: 17.6.4.9 [res.on.arguments], 17.6.3.1 [utility.arg.requirements], 17.6.5.15 [lib.types.movedfrom], 23.2.1 [container.requirements.general] Status: New Submitter: Matt Austern Opened: 2015-01-22 Last modified: 2015-04-08

View all other issues in [res.on.arguments].

View all issues with New status.

Discussion:

Suppose we write

vector<string> v{"a", "b", "c", "d"};
v = move(v);

What should be the state of v be? The standard doesn't say anything specific about self-move-assignment. There's relevant text in several parts of the standard, and it's not clear how to reconcile them.

17.6.4.9 [res.on.arguments] writes that, for all functions in the standard library, unless explicitly stated otherwise, "If a function argument binds to an rvalue reference parameter, the implementation may assume that this parameter is a unique reference to this argument." The MoveAssignable requirements table in 17.6.3.1 [utility.arg.requirements] writes that, given t = rv, t's state is equivalent to rv's from before the assignment and rv's state is unspecified (but valid). For containers specifically, the requirements table in 23.2.1 [container.requirements.general] says that, given a = rv, a becomes equal to what rv was before the assignment (and doesn't say anything about rv's state post-assignment).

Taking each of these pieces in isolation, without reference to the other two:

It's not clear from the text how to put these pieces together, because it's not clear which one takes precedence. Maybe 17.6.4.9 [res.on.arguments] wins (it imposes an implicit precondition that isn't mentioned in the MoveAssignable requirements, so v = move(v) is undefined), or maybe 23.2.1 [container.requirements.general] wins (it explicitly gives additional guarantees for Container::operator= beyond what's guaranteed for library functions in general, so v = move(v) is a no-op), or maybe something else.

On the existing implementations that I checked, for what it's worth, v = move(v) appeared to clear the vector; it didn't leave the vector unchanged and it didn't cause a crash.

Proposed wording:

Informally: change the MoveAssignable and Container requirements tables (and any other requirements tables that mention move assignment, if any) to make it explicit that x = move(x) is defined behavior and it leaves x in a valid but unspecified state. That's probably not what the standard says today, but it's probably what we intended and it's consistent with what we've told users and with what implementations actually do.

Proposed resolution:


2471. copy_n's number of InputIterator increments unspecified

Section: 25.3.1 [alg.copy] Status: New Submitter: Jonathan Wakely Opened: 2015-01-28 Last modified: 2015-05-04

View other active issues in [alg.copy].

View all other issues in [alg.copy].

View all issues with New status.

Discussion:

It's unspecified how many times copy_n increments the InputIterator. uninitialized_copy_n is specified to increment it exactly n times, which means if an istream_iterator is used then the next character after those copied is read from the stream and then discarded, losing data.

I believe all three of Dinkumware, libc++ and libstdc++ implement copy_n with n - 1 increments of the InputIterator, which avoids reading and discarding a character when used with istream_iterator, but is inconsistent with uninitialized_copy_n and causes surprising behaviour with istreambuf_iterator instead, because copy_n(in, 2, copy_n(in, 2, out)) is not equivalent to copy_n(in, 4, out)

Proposed resolution:


2472. Heterogeneous comparisons in the standard library can result in ambiguities

Section: 20.4.2.7 [tuple.rel], 20.7.9.2 [allocator.globals], 20.8.1.5 [unique.ptr.special], 20.8.2.2.7 [util.smartptr.shared.cmp], 20.12.5.6 [time.duration.comparisons], 20.12.6.6 [time.point.comparisons], 20.13.5 [scoped.adaptor.operators], 24.5.1.3.13 [reverse.iter.op==], 24.5.3.3.13 [move.iter.op.comp] Status: New Submitter: Richard Smith Opened: 2015-02-07 Last modified: 2015-05-04

View other active issues in [tuple.rel].

View all other issues in [tuple.rel].

View all issues with New status.

Discussion:

The standard library specifies a lot of heterogeneous comparison operators. For instance:

template<class... TTypes, class... UTypes>
constexpr bool operator!=(const tuple<TTypes...>&, const tuple<UTypes...>&);

This has an unfortunate consequence:

#include <tuple>
#include <utility>

using namespace std::rel_ops;
std::tuple<int> a(0);
bool b = a != a;

The last line here is ill-formed due to ambiguity: it might be rel_ops::operator!=, and it might be the heterogeneous tuple operator!=. These are not partially ordered, because they have different constraints: rel_ops requires the types to match, whereas the tuple comparison requires both types to be tuples (but not to match). The same thing happens for user code that defines its own unconstrained 'template<typename T> operator!=(const T&, const T&)' rather than using rel_ops.

One straightforward fix would be to add a homogeneous overload for each heterogeneous comparison:

template<class... TTypes>
constexpr bool operator!=(const tuple<TTypes...>&, const tuple<TTypes...>&);

This is then unambiguously chosen over the other options in the preceding case. FWIW, libstdc++ already does this in some cases.

Proposed resolution:


2474. <cmath> functions unfriendly to integral_constant arguments

Section: 26.8 [c.math] Status: New Submitter: Matheus Izvekov Opened: 2015-02-13 Last modified: 2015-05-04

View other active issues in [c.math].

View all other issues in [c.math].

View all issues with New status.

Discussion:

Using numeric wrappers with <cmath> functions is currently troublesome. Code such as: "std::exp2(std::integral_constant<int, 5>{})" will fail to compile because of ambiguity.

Arguments which are implicitly convertible to an arithmetic type should be accepted whenever the latter would be accepted.

David Krauss pointed out that some issue may present itself with numeric libraries which provide <cmath> equivalents in their own namespace which are not more specialized than the ones provided in <cmath>. If the changes proposed are implemented, then cases where the user brings those into scope through ADL might become ambiguous.

It's hard to assess how much breakage this would cause in the wild, and how much work it would take to fix. Should this be determined to be a problem, it's possible to make the new behaviour optional, and disabled by default for all user-defined types.

Proposed resolution:

This wording is relative to N4296.

  1. Change 26.8 [c.math] p11 b2 as indicated:

    -11- Moreover, there shall be additional overloads sufficient to ensure:

    1. […]

    2. Otherwise, if any arithmetic argument corresponding to a double parameter has type double or an integer typea type which is not floating-point, but which is implicitly convertible to double, then all arithmetic arguments corresponding to double parameters are effectively cast to double.

    3. […]


2475. Allow overwriting of std::basic_string terminator with charT() to allow cleaner interoperation with legacy APIs

Section: 21.4.5 [string.access] Status: New Submitter: Matt Weber Opened: 2015-02-21 Last modified: 2015-05-04

View all other issues in [string.access].

View all issues with New status.

Discussion:

It is often desirable to use a std::basic_string object as a buffer when interoperating with libraries that mutate null-terminated arrays of characters. In many cases, these legacy APIs write a null terminator at the specified end of the provided buffer. Providing such a function with an appropriately-sized std::basic_string results in undefined behavior when the charT object at the size() position is overwritten, even if the value remains unchanged.

Absent the ability to allow for this, applications are forced into pessimizations such as: providing appropriately-sized std::vectors of charT for interoperating with the legacy API, and then copying the std::vector to a std::basic_string; providing an oversized std::basic_string object and then calling resize() later.

A trivial example:

#include <string>
#include <vector>

void legacy_function(char *out, size_t count) {
  for (size_t i = 0; i < count; ++i) {
    *out++ = '0' + (i % 10);
  }
  *out = '\0'; // if size() == count, this results in undefined behavior
}

int main() {
  std::string s(10, '\0');
  legacy_function(&s[0], s.size()); // undefined behavior

  std::vector<char> buffer(11);
  legacy_function(&buffer[0], buffer.size() - 1);
  std::string t(&buffer[0], buffer.size() - 1); // potentially expensive copy

  std::string u(11, '\0');
  legacy_function(&u[0], u.size() - 1);
  u.resize(u.size() - 1); // needlessly complicates the program's logic
}

A slight relaxation of the requirement on the returned object from the element access operator would allow for this interaction with no semantic change to existing programs.

Proposed resolution:

This wording is relative to N4296.

  1. Edit 21.4.5 [string.access] as indicated:

    const_reference operator[](size_type pos) const;
    reference operator[](size_type pos);
    

    -1- Requires: […]

    -2- Returns: *(begin() + pos) if pos < size(). Otherwise, returns a reference to an object of type charT with value charT(), where modifying the object to any value other than charT() leads to undefined behavior.

    […]


2478. Unclear how wstring_convert uses cvtstate

Section: 22.3.3.2.2 [conversions.string] Status: New Submitter: Jonathan Wakely Opened: 2015-03-04 Last modified: 2015-05-04

View other active issues in [conversions.string].

View all other issues in [conversions.string].

View all issues with New status.

Discussion:

How do wstring_convert::from_bytes and wstring_convert::to_bytes use the cvtstate member?

Is it passed to the codecvt member functions? Is a copy of it passed to the member functions? "Otherwise it shall be left unchanged" implies a copy is used, but if that's really what's intended there are simpler ways to say so.

Proposed resolution:


2479. Unclear how wbuffer_convert uses cvtstate

Section: 22.3.3.2.3 [conversions.buffer] Status: New Submitter: Jonathan Wakely Opened: 2015-03-04 Last modified: 2015-05-04

View other active issues in [conversions.buffer].

View all other issues in [conversions.buffer].

View all issues with New status.

Discussion:

How does wbuffer_convert use the cvtstate member?

Is the same conversion state object used for converting both the get and put areas? That means a read which runs out of bytes halfway through a multibyte character will leave some shift state in cvtstate, which would then be used by a following write, even though the shift state of the get area is unrelated to the put area.

Proposed resolution:


2480. Error handling of wbuffer_convert unclear

Section: 22.3.3.2.3 [conversions.buffer] Status: New Submitter: Jonathan Wakely Opened: 2015-03-04 Last modified: 2015-05-04

View other active issues in [conversions.buffer].

View all other issues in [conversions.buffer].

View all issues with New status.

Discussion:

If a codecvt conversion returns codecvt_base::error should that be treated as EOF? An exception? Should all the successfully converted characters before a conversion error be available to the users of the wbuffer_convert and/or the internal streambuf, or does a conversion error lose information?

Proposed resolution:


2481. wstring_convert should be more precise regarding "byte-error string" etc.

Section: 22.3.3.2.2 [conversions.string] Status: New Submitter: Jonathan Wakely Opened: 2015-03-04 Last modified: 2015-05-04

View other active issues in [conversions.string].

View all other issues in [conversions.string].

View all issues with New status.

Discussion:

Paragraph 4 of 22.3.3.2.2 [conversions.string] introduces byte_err_string as "a byte string to display on errors". What does display mean? The string is returned on error, it's not displayed anywhere.

Paragraph 14 says "Otherwise, if the object was constructed with a byte-error string, the member function shall return the byte-error string." The term byte-error string is not used anywhere else.

Paragraph 17 talks about storing "default values in byte_err_string". What default value? Is "Hello, world!" allowed? If it means default-construction it should say so. If paragraph 14 says it won't be used what does it matter how it's initialized? The end of the paragraph refers to storing "byte_err in byte_err_string". This should be more clearly related to the wording in paragraph 14.

It might help if the constructor (and destructor) was specified before the other member functions, so it can more formally define the difference between being "constructed with a byte-error string" and not.

All the same issues apply to the wide_err_string member.

Proposed resolution:


2490. <regex> needs lots of noexcept

Section: 28 [re] Status: New Submitter: Stephan T. Lavavej Opened: 2015-03-27 Last modified: 2015-05-04

View other active issues in [re].

View all other issues in [re].

View all issues with New status.

Discussion:

Only 4 functions are marked noexcept in all of Clause 28. Many more need to be marked — for example, regex_error::code(), basic_regex::swap(), and sub_match::length().

Proposed resolution:


2491. std::less<T*> in constant expression

Section: 20.9.6 [comparisons] Status: New Submitter: Agustín K-ballo Bergé Opened: 2015-04-01 Last modified: 2015-05-04

View other active issues in [comparisons].

View all other issues in [comparisons].

View all issues with New status.

Discussion:

It is not entirely clear if and when the specializations of std::less (and friends) for pointer types can be used in a constant expression. Consider the following code:

#include <functional>

struct foo {};
foo x, y;
constexpr bool b = std::less<foo*>{}(&x, &y); // [1]

foo z[] = {{}, {}};
constexpr bool ba = std::less<foo*>{}(&z[0], &z[1]); // [2]

Comparing the address of unrelated objects is not a constant expression since the result is unspecified, so it could be expected for [1] to fail and [2] to succeed. However, std::less specialization for pointer types is well-defined and yields a total order, so it could just as well be expected for [1] to succeed. Finally, since the implementation of such specializations is not mandated, [2] could fail as well (This could happen, if an implementation would provide such a specialization and if that would use built-in functions that would not be allowed in constant expressions, for example). In any case, the standard should be clear so as to avoid implementation-defined constexpr-ness.

Proposed resolution:


2493. initializer_list supports incomplete classes

Section: 18.9 [support.initlist] Status: New Submitter: David Krauss Opened: 2015-04-27 Last modified: 2015-05-04

View other active issues in [support.initlist].

View all other issues in [support.initlist].

View all issues with New status.

Discussion:

The typical use-case of std::initializer_list<T> is for a pass-by-value parameter of T's constructor. However, this contravenes 17.6.4.8 [res.on.functions]/2.5 because initializer_list doesn't specifically allow incomplete types (as do for example std::unique_ptr (20.8.1 [unique.ptr]/5) and std::enable_shared_from_this (20.8.2.5 [util.smartptr.enab]/2)).

A resolution would be to copy-paste the relevant text from such a paragraph.

Proposed resolution:


2495. There is no such thing as an Exception Safety element

Section: 20.8.2.2.1 [util.smartptr.shared.const] Status: New Submitter: Jonathan Wakely Opened: 2015-05-05 Last modified: 2015-05-20

View all other issues in [util.smartptr.shared.const].

View all issues with New status.

Discussion:

20.8.2.2.1 [util.smartptr.shared.const] includes several "Exception safety" elements, but that is not one of the elements defined in 17.5.1.4 17.5.1.4 [structure.specifications]. We should either define what it means, or just move those sentences into the Effects: clause.

Proposed resolution:

This wording is relative to N4431.

  1. Change 20.8.2.2.1 [util.smartptr.shared.const] as follows:

    template<class Y> explicit shared_ptr(Y* p);
    

    […]

    -4- Effects: Constructs a shared_ptr object that owns the pointer p. If an exception is thrown, delete p is called.

    […]

    -7- Exception safety: If an exception is thrown, delete p is called.

    template <class Y, class D> shared_ptr(Y* p, D d);
    template <class Y, class D, class A> shared_ptr(Y* p, D d, A a);
    template <class D> shared_ptr(nullptr_t p, D d);
    template <class D, class A> shared_ptr(nullptr_t p, D d, A a);
    

    […]

    -9- Effects: Constructs a shared_ptr object that owns the object p and the deleter d. The second and fourth constructors shall use a copy of a to allocate memory for internal use. If an exception is thrown, d(p) is called.

    […]

    -12- Exception safety: If an exception is thrown, d(p) is called.

    […]
    template <class Y> explicit shared_ptr(const weak_ptr<Y>& r);
    

    […]

    -24- Effects: Constructs a shared_ptr object that shares ownership with r and stores a copy of the pointer stored in r. If an exception is thrown, the constructor has no effect.

    […]

    -27- Exception safety: If an exception is thrown, the constructor has no effect.

    template <class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);
    

    […]

    -29- Effects: Equivalent to shared_ptr(r.release(), r.get_deleter()) when D is not a reference type, otherwise shared_ptr(r.release(), ref(r.get_deleter())). If an exception is thrown, the constructor has no effect.

    -30- Exception safety: If an exception is thrown, the constructor has no effect.


2496. Certain hard-to-avoid errors not in the immediate context are not allowed to be triggered by the evaluation of type traits

Section: 20.10.4.3 [meta.unary.prop] Status: New Submitter: Hubert Tong Opened: 2015-05-07 Last modified: 2015-05-20

View other active issues in [meta.unary.prop].

View all other issues in [meta.unary.prop].

View all issues with New status.

Discussion:

I do not believe that the wording in 20.10.4.3 [meta.unary.prop] paragraph 3 allows for the following program to be ill-formed:

#include <type_traits>

template <typename T> struct B : T { };
template <typename T> struct A { A& operator=(const B<T>&); };

std::is_assignable<A<int>, int> q;

In particular, I do not see where the wording allows for the "compilation of the expression" declval<T>() = declval<U>() to occur as a consequence of instantiating std::is_assignable<T, U> (where T and U are, respectively, A<int> and int in the example code).

Instantiating A<int> as a result of requiring it to be a complete type does not trigger the instantiation of B<int>; however, the "compilation of the expression" in question does.

Proposed resolution:


2497. Use of uncaught_exception()

Section: 27.7.3.4 [ostream::sentry] Status: New Submitter: Roger Orr Opened: 2015-05-08 Last modified: 2015-05-20

View all other issues in [ostream::sentry].

View all issues with New status.

Discussion:

In the current 27.7.3.4 [ostream::sentry], p4 refers to the now deprecated std::uncaught_exception(): D.9 [depr.uncaught].

If ((os.flags() & ios_base::unitbuf) && !uncaught_exception() && os.good()) is true, calls os.rdbuf()->pubsync().

This needs to be changed, for example to use std::uncaught_exceptions() and to capture the value on entry and compare with the saved value on exit.

Proposed resolution:


2498. operator>>(basic_istream&&, T&&) returns basic_istream&, but should probably return basic_istream&&

Section: 27.7.2.6 [istream.rvalue] Status: New Submitter: Richard Smith Opened: 2015-05-08 Last modified: 2015-05-20

View other active issues in [istream.rvalue].

View all other issues in [istream.rvalue].

View all issues with New status.

Discussion:

Consider:

auto& is = make_istream() >> x; // oops, istream object is already gone

With a basic_istream&& return type, the above would be ill-formed, and generally we'd preserve the value category properly.

Proposed resolution:


2499. operator>>(basic_istream&, CharT*) makes it hard to avoid buffer overflows

Section: 27.7.2.2.3 [istream::extractors] Status: New Submitter: Richard Smith Opened: 2015-05-08 Last modified: 2015-05-21

View all other issues in [istream::extractors].

View all issues with New status.

Discussion:

We removed gets() (due to an NB comment and C11 — bastion of backwards compatibility — doing the same). Should we remove this too?

Unlike gets(), there are legitimate uses:

char buffer[32];
char text[32] = // ...
ostream_for_buffer(text) >> buffer; // ok, can't overrun buffer

… but the risk from constructs like "std::cin >> buffer" seems to outweigh the benefit.

The issue had been discussed on the library reflector starting around c++std-lib-35541.

Proposed resolution:


2500. [fund.ts.v2] fundts.memory.smartptr.shared.obs/6 should apply to cv-unqualified void

Section: X [memory.smartptr.shared.obs] Status: New Submitter: Jeffrey Yasskin Opened: 2015-05-11 Last modified: 2015-05-20

View all issues with New status.

Discussion:

Addresses: fund.ts.v2

S. B. Tam reported this here.

N3920 changed operator*() in [util.smartptr.shared.obs] as:

Remarks: When T is an array type or cv-qualified void, it is unspecified whether this member function is declared. …

This excludes cv-unqualified void, which is probably unintended.

Proposed resolution:

  1. In the library fundamentals v2, [memory.smartptr.shared.obs] p2, change as indicated:

    Remarks: When T is an array type or (possibly cv-qualified) void, it is unspecified whether this member function is declared. If it is declared, it is unspecified what its return type is, except that the declaration (although not necessarily the definition) of the function shall be well formed.


2501. std::function requires POCMA/POCCA

Section: 20.9.12.2 [func.wrap.func] Status: New Submitter: David Krauss Opened: 2015-05-20 Last modified: 2015-05-22

View other active issues in [func.wrap.func].

View all other issues in [func.wrap.func].

View all issues with New status.

Discussion:

The idea behind propagate_on_container_move_assignment is that you can keep an allocator attached to a container. But it's not really designed to work with polymorphism, which introduces the condition where the current allocator is non-POCMA and the RHS of assignment, being POCMA, wants to replace it. If function were to respect the literal meaning, any would-be attached allocator is at the mercy of every assignment operation. So, std::function is inherently POCMA, and passing a non-POCMA allocator should be ill-formed.

The other alternative, and the status quo, is to ignore POCMA and assume it is true. This seems just dangerous enough to outlaw. It is, in theory, possible to properly support POCMA as far as I can see, albeit with difficulty and brittle results. It would require function to keep a throwing move constructor, which otherwise can be noexcept.

The same applies to propagate_on_container_copy_assignment. This presents more difficulty because std::allocator does not set this to true. Perhaps it should. For function to respect this would require inspecting the POCCA of the source allocator, slicing the target from the erasure of the source, slicing the allocation from the erasure of the destination, and performing a copy with the destination's allocator with the source's target. This comes out of the blue for the destination allocator, which might not support the new type anyway. Theoretically possible, but brittle and not very practical. Again, current implementations quietly ignore the issue but this isn't very clean.

The following code example is intended to demonstrate the issue here:

#include <functional>
#include <iostream>
#include <vector>

template <typename T>
struct diag_alloc 
{
  std::string name;

  T* allocate(std::size_t n) const 
  {
    std::cout << '+' << name << '\n';
    return static_cast<T*>(::operator new(n * sizeof(T)));
  }
  
  void deallocate(T* p, std::size_t) const 
  {
    std::cout << '-' << name << '\n';
    return ::operator delete(p);
  }

  template <typename U>
  operator diag_alloc<U>() const { return {name}; }

  friend bool operator==(const diag_alloc& a, const diag_alloc& b)
  { return a.name == b.name; }
  
  friend bool operator!=(const diag_alloc& a, const diag_alloc& b)
  { return a.name != b.name; }

  typedef T value_type;
  
  template <typename U>
  struct rebind { typedef diag_alloc<U> other; };
};

int main() {
  std::cout << "VECTOR\n";
  std::vector<int, diag_alloc<int>> foo({1, 2}, {"foo"}); // +foo
  std::vector<int, diag_alloc<int>> bar({3, 4}, {"bar"}); // +bar

  std::cout << "move\n";
  foo = std::move(bar); // no message

  std::cout << "more foo\n";
  foo.reserve(40); // +foo -foo
  std::cout << "more bar\n";
  bar.reserve(40); // +bar -bar

  std::cout << "\nFUNCTION\n";
  int bigdata[100];
  auto bigfun = [bigdata]{};
  typedef decltype(bigfun) ft;
  std::cout << "make fizz\n";
  std::function<void()> fizz(std::allocator_arg, diag_alloc<ft>{"fizz"}, bigfun); // +fizz
  std::cout << "another fizz\n";
  std::function<void()> fizz2;
  fizz2 = fizz; // +fizz as if POCCA
  std::cout << "make buzz\n";
  std::function<void()> buzz(std::allocator_arg, diag_alloc<ft>{"buzz"}, bigfun); // +buzz
  std::cout << "move\n";
  buzz = std::move(fizz); // -buzz as if POCMA

  std::cout << "\nCLEANUP\n";
}

Proposed resolution:


2502. std::function does not use allocator::construct

Section: 20.9.12.2 [func.wrap.func] Status: New Submitter: David Krauss Opened: 2015-05-20 Last modified: 2015-05-21

View other active issues in [func.wrap.func].

View all other issues in [func.wrap.func].

View all issues with New status.

Discussion:

It is impossible for std::function to construct its target object using the construct method of a type-erased allocator. More confusingly, it is possible when the allocator and the target are created at the same time. The means of target construction should be specified.

Proposed resolution:


2503. multiline option should be added to syntax_option_type

Section: 28.5.1 [re.synopt] Status: New Submitter: Nozomu Katō Opened: 2015-05-22 Last modified: 2015-05-22

View other active issues in [re.synopt].

View all other issues in [re.synopt].

View all issues with New status.

Discussion:

The specification of ECMAScript defines the Multiline property for its RegExp and the regular expressions ^ and $ behave differently according to the value of this property. Thus, this property should be available also in the ECMAScript compatible engine in std::regex.

[2015-05-22, Daniel comments]

This issue interacts somewhat with LWG 2343.

Proposed resolution:

This wording is relative to N4431.

  1. Change 28.5.1 [re.synopt] as indicated:

    namespace std::regex_constants {
      typedef T1 syntax_option_type;
      constexpr syntax_option_type icase = unspecified ;
      constexpr syntax_option_type nosubs = unspecified ;
      constexpr syntax_option_type optimize = unspecified ;
      constexpr syntax_option_type collate = unspecified ;
      constexpr syntax_option_type ECMAScript = unspecified ;
      constexpr syntax_option_type basic = unspecified ;
      constexpr syntax_option_type extended = unspecified ;
      constexpr syntax_option_type awk = unspecified ;
      constexpr syntax_option_type grep = unspecified ;
      constexpr syntax_option_type egrep = unspecified ;
      constexpr syntax_option_type multiline = unspecified ;
    }
    
  2. Change 28.5.2 [re.matchflag], Table 138 — "syntax_option_type effects" as indicated:

    Table 138 — syntax_option_type effects
    Element Effect(s) if set
    multiline Specifies that ^ shall match the beginning of a line and $ shall match the end of a line, if the ECMAScript engine is selected.