Date: 2017-06-16
Project: C++ Extensions for Concepts
Reply to: Andrew Sutton <asutton@uakron.edu>

C++ Concepts Completed Issues List (Revision 5)

Revised 2017-06-16 at 16:06:02 UTC

Reference ISO/IEC TS 19217

Also see:

This document contains only concepts issues which have been closed by the Core Working Group (CWG) after being found to be acceptable extensions to the standard. That is, issues which have a status of DR, TC1, WP, C++11, or Resolved. See the Concepts Closed Issues List for issues closed as non-defects. See the Concepts Active Issues List for active issues and more information. The introductory material in that document also applies to this document.

Revision History

Completed Issues

3. Allow requires-expressions in more contexts

Section: 5.1.4 [expr.prim.req] Status: WP Submitter: US Opened: 2015-05-18 Last modified: 2017-06-16

View all other issues in [expr.prim.req].

View all issues with WP status.

Discussion:

The following requirement seems overly restrictive, as it can be fairly easily (but tediously) be worked around: "A requires-expression shall appear only within a concept definition (7.1.7), or within the requires-clause of a template declaration (Clause 14) or function declaration (8.3.5)." (The tedious workaround for each concept C is to define an overload set consisting of two function templates, one unconstrained and returning false, the other constrained by C and returning true.)

Proposed change: Eliminate the requirement, thereby permitting other uses for this new kind of expression of type bool. (For example, requires­-expressions might replace many or all of the Boolean type traits.) Additionally, in any context where a bool value is permitted, allow a concept’s name plus suitable arguments to denote the truth value of the claim that "this combination of arguments satisfy this concept." (This syntax is currently valid in only certain contexts such as requires­expressions.)

There is a paper addressing the requires-expression portion of this discussion. .

Issue 29 was created to specifically address the inability to evaluate concepts outside of SFINAE contexts.

26. Function concepts not allowed to be declared in more than one TU

Section: 14.10.3 [temp.constr.order] Status: WP Submitter: Hubert Tong Opened: 2015-06-09 Last modified: 2017-06-16

View other active issues in [temp.constr.order].

View all other issues in [temp.constr.order].

View all issues with WP status.

Discussion:

According to subclause 7.1.7 [dcl.spec.concept] paragraph 1:

When a function is declared to be a concept, it shall be the only declaration of that function.

Wording available:

Change that sentence to read:
When a function template is declared to be a concept, it shall be the only declaration of that function template in the translation unit.

29. Allow concepts to be evaluated in any context

Section: 14.10.2 [temp.constr.decl] Status: WP Submitter: Andrew Sutton Opened: 2016-02-27 Last modified: 2017-06-16

View other active issues in [temp.constr.decl].

View all other issues in [temp.constr.decl].

View all issues with WP status.

Discussion:

Currently, concepts are only guaranteed to be evaluable within the context of a requires-expression. Among other things, this guarantees that the following will not work: static_assert(C<X>(), ""); // for some concrete X

Evaluating a concept in any context effectively requires that it be evaluated as if in a SFINAE context. The original design of concepts did not require this because it was not clear how easy this would be for all implementers. Based on EWG discussions in Kona, this appears to no longer be the case.

This issue is submitted as a result of an EWG straw poll taken during discussion of issue 3.

Wording available: