C++ Concepts Active Issues List (Revision C4)

Also see:

• Table of Contents for all concepts issues.
• Index by Section for all concepts issues.
• Index by Status for all concepts issues.
• Concepts Defect Report List
• Concepts Closed Issues List

The purpose of this document is to record the status of issues which have been related to the authors of the C++ concepts proposals. Issues represent potential defects in the language or library proposals for concepts.

This document contains only issues which are actively being considered for concepts. That is, issues which have a status of New, Open, Ready, and Review. See Concepts Defect Report List for issues considered defects and Concepts Closed Issues List for issues considered closed.

Revision History

• C4: Companion to the concepts proposals in the post-Antipolis mailing. (30 June 2008)
• C3: Companion to the concepts proposals in the pre-Sophia-Antipolis mailing. (19 May 2008)
• C2: Companion to the concepts proposals in the Post-Bellevue mailing. (25 Mar 2008)
• C1: Initial version. (3 Mar 2008)

Issue Status

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

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

• Consensus may have not yet have been reached as to how to deal with the issue.
• Informal consensus may have been reached, but the committee awaits exact Proposed Resolution wording for review.
• The committee wishes to consult additional technical experts before proceeding.
• The issue may require further study.

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

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

NAD - The committee has reached consensus that the issue is not a defect in the concepts proposal.

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

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

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

Ready - The committee has reached consensus that the issue is a defect in the concepts proposal, the Proposed Resolution is correct, and the issue is ready to be integrated into the next concepts proposal.

WP - (Concepts Defect) - The committee has decided to accept the proposed resolution and the resolution is part of a concepts proposal draft.

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

Issues are always given the status of New when they first appear on the issues list. They may progress to Open or Review while the committee is actively working on them. When the committee has reached consensus on the disposition of an issue, the status will then change to Dup, NAD, or Ready as appropriate. Once a Ready issue has made it into a draft of the concepts proposal, it is given the status of Working Paper ( WP). To streamline the process for concepts (since it is still a proposal, not part of the committee working paper), we will often skip the Review or Ready status.

Active Issues

21. Iterator difference_type requirements

Section: 24.1.1 [input.iterators] Status: New Submitter: LWG Date: 2008-02-28

View all other issues in [input.iterators].

View all issues with New status.

Discussion:

InputIterator currently requires that its difference type be both an IntegerType and SignedIntegralLike. There are two issues here. First, why do we need to require both? Answer: one of those is a compiler-generated concept saying that it must be one of a specific list of built-in types, but it doesn't declare anything about the operations, so it doesn't allow you to actually write things like +. But that's very weird. If we know that we've constrained it to be one of a small number of types, shouldn't we be able to use those operations that those types all have in common? Second, just why are we requiring it to be one of the types in that list? If I have my own type that I can use for counting (i.e. an abelian group), then why can't I use it for the iterator's difference type?

27. Missing core concept for polymorphic types

Section: 20.1.1 [concept.support] Status: New Submitter: Alisdair Meredith Date: 2008-03-25

View other active issues in [concept.support].

View all other issues in [concept.support].

View all issues with New status.

Discussion:

There is no core concept for Polymorphic types in n2572. This seems to be a useful concept where we expect dynamic_cast to return something useful.

Proposed resolution:

Add to the synopsis of the header <concepts>:

concept ClassType<typename T> see below; 
concept Class<typename T> see below; 
concept PolymorphicClass<typename T> see below;
concept Union<typename T> see below;
  

Add the following to [concept.support], after the description of concept Class:

concept PolymorphicClass<typename T> : Class<T> { }
  

16. Note: describes polymorphic types ([class.virtual]).
17. Requires: for every type T that is a polymorphic class, a concept map PolymorphicClass<T> shall be implicitly defined in namespace std.

28. Abstract classes should not be VariableTypes

Section: 20.1.1 [concept.support] Status: New Submitter: Thomas Witt Date: 2008-03-25

View other active issues in [concept.support].

View all other issues in [concept.support].

View all issues with New status.

Discussion:

Since one cannot create an instance of an abstract class, an abstract class type T should not have an implicitly-defined concept map VariableType<T>.

Proposed resolution:

Modify [concept.support]p9 as follows:

9. Requires: for every type T that is an object type or reference type, but not an abstract class type ([class.abstract]), a concept map VariableType<T> shall be implicitly defined in namespace std.

37. Relation between move/swap concepts and Regular

Section: 20.1.7 [concept.regular] Status: New Submitter: Chris Jefferson Date: 2008-05-30

View all other issues in [concept.regular].

View all issues with New status.

Discussion:

I've been thinking about rearranging these things:

1. Have a 'move equivalent' version of Regular/SemiRegular.
2. Move Swappable into Regular/SemiRegular.

The reason for 2 is I expect for many people (it has been for me) Regular will be their standard concept to use for "types which are normal / sensible". The fact you can't sort a Regular type (as it isn't Swappable) seems a bit bizarre.

38. Container move constructor/assignment operators don't account for scoped allocators

Section: 23 [containers] Status: Open Submitter: Pablo Halpern Date: 2008-05-29

View all other issues in [containers].

Discussion:

The requirements for extended move construction are correct table 91, but missing in the requires clauses in N2623. The requirements on the normal move constructor and the move assignment operator are missing.

41. MoveConstructible constructor should be explicit

Section: 20.1.5 [concept.copymove] Status: New Submitter: LWG Date: 2008-06-09

View all other issues in [concept.copymove].

View all issues with New status.

Discussion:

Users are permitted to use types with explicit copy and move constructors with the C++98 standard library. To support this use case with concepts, the constructor requirements in MoveConstructible and CopyConstructible need to be explicit.

Proposed resolution:

Modify [concept.copymove] paragraphs 1-3 as follows:

auto concept MoveConstructible<typename T> : HasConstructor<T, T&&> { 
  explicit T::T(T&&);
}
  

1. Note: describes types that can move-construct an object from a value of the same type, possibly altering that value.

T::T(T&& rv); // note: inherited from HasConstructor<T, T&&>
  

2. Postcondition: the constructed T object is equivalent to the value of rv before the construction. [ Note: there is no requirement on the value of rv after the construction. - end note ]

auto concept CopyConstructible<typename T> : MoveConstructible<T>, HasConstructor<T, const T&> { 
  T::T(const T&);

  axiom CopyPreservation(T x) { 
    T(x) == x; 
  } 
}