| Date: | 2017-06-16 |
| Project: | C++ Extensions for Concepts |
| Reply to: | Andrew Sutton <asutton@uakron.edu> |
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 as duplicates or not defects. That is, issues which have a status of Dup or NAD. See the Concepts Active Issues List active issues and more information. See the Concepts Complete Issues List for issues considered accepted extensions. The introductory material in that document also applies to this document.
Section: 7.1.7 [dcl.spec.concept] Status: NAD Submitter: FI Opened: 2015-05-18 Last modified: 2017-06-12
View other active issues in [dcl.spec.concept].
View all other issues in [dcl.spec.concept].
View all issues with NAD status.
Discussion:
It seems unfortunate that concepts cannot be declared as members of class
templates. This seemingly makes it impossible to define concepts for
constraining multiple template parameter packs (if concepts as static member
functions were possible, one could provide e.g. two packs so that the class
template gets the first pack and the member function template gets the
second. That can't be done with a namespace scope concept because multiple
packs in function templates require deduction, and concepts don't take
arguments that could be deduced.). As an example, practical needs for such
constraining arise in standard library implementations, when constraining
the variadic converting constructors of std::tuple.
Suggest opening an EWG issue.
Rationale:
EWG was neutral on this topic. Suggest a paper with rationale and wording.Section: 5.1.4.3 [expr.prim.req.compound] Status: NAD Submitter: US Opened: 2015-05-18 Last modified: 2017-06-12
View all other issues in [expr.prim.req.compound].
View all issues with NAD status.
Discussion:
We believe that (generally speaking) the non throwing of exceptions is a
part of the runtime contract of a function, not something that should be
advertised in the type system outside a few very specific cases related to
move operations. As a requires expression is always free to invoke the
noexcept operator to produce a predicate, we believe that is sufficient
support for exception constraints in the language, and directly
supporting this additional term in the grammar would be harmful, encouraging
compile-time contracts taking away an important library implementer freedom.
As the TS is intended to provide feedback, we believe it would be better to
proceed without this, and see how much demand arises from using the
alternate form, and whether that alternate form alone is too cumbersome for
real world use.
Simplify the compound-requirement: term in 5.1.4.3:
{ expression } [noexcept] [trailing-return-type]
Strike 14.10.1.7.
Also see 5 as it relates.
Suggest opening an EWG issue.
Rationale:
EWG was against dropping the noexcept keyword.Section: 5.1.4.3 [expr.prim.req.compound] Status: NAD Submitter: US Opened: 2015-05-18 Last modified: 2017-06-12
View all other issues in [expr.prim.req.compound].
View all issues with NAD status.
Discussion:
If we retain exception constraints, the optional `noexcept` specifier should support the full range of the noexcept grammar. Amend compound-requirement:
{ expression } [noexcept] [noexcept-specification] [trailing-return-type]
Also see 4 as it relates.
Suggest opening an EWG issue.
Rationale:
EWG was against adding full exception specifications to compound requirements.Section: 7.1.6.4.2 [dcl.spec.auto.constr] Status: NAD Submitter: US Opened: 2015-05-18 Last modified: 2017-06-12
View all other issues in [dcl.spec.auto.constr].
View all issues with NAD status.
Discussion:
We have a broad concern that the ambiguity for a reader between a constrained function template without a template-introducer and a "regular" function will make the language unnecessarily difficult to teach, read, and maintain code. We note that a TS is the perfect vehicle to have an experiment to establish if these concerns are real, but want to exercise caution as we proceed, and be sure that there is a real feedback plan in place before considering moving this feature from a TS and into a future standard.
Suggest opening an EWG issue.
Rationale:
EWG is against dropping the terse notation from the design of concepts.Section: 14.10.2 [temp.constr.decl] Status: NAD Submitter: US Opened: 2015-05-18 Last modified: 2017-06-12
View other active issues in [temp.constr.decl].
View all other issues in [temp.constr.decl].
View all issues with NAD status.
Discussion:
There are too many redundant ways to express the same set of requirements. While each presents a reasonable use-case in isolation, the combined effect is overwhelming. Proposed solution: Review the overlapping syntaxes, and eliminate those that add least value, or are least frequently used. This may mean shipping the TS in close to its current form to obtain such feedback though.
Suggest opening an EWG issue.
Rationale:
The issue is too broadly stated. There is nothing specific for EWG to address as an issue.Section: 14.10.1.1 [temp.constr.conv] Status: NAD Submitter: US Opened: 2015-05-18 Last modified: 2017-06-12
View all other issues in [temp.constr.conv].
View all issues with NAD status.
Discussion:
This paragraph introduces implicit conversion constraints to specify (via the
trailing-return-type notation ->) that a constraint is satisfied iff an
expression E is convertible to a type T. It would be very useful to have
similar constraints that are satisfied iff decltype(E) is exactly the type
T.
Introduce new notation (e.g., E => T) to denote a constraint that is
satisfied iff the expression E has precisely the type T. Here is a
practical example of the utility of such a feature:
template <typename T>
concept bool CopyAssignable = requires (T a, T b) {
{ a = b } => T const&;
};
This is a proposal for an extension and is better addressed in EWG.
Rationale:
EWG is not in favor of adding this feature.Section: 12.1 [class.ctor] Status: Dup Submitter: Casey Carter Opened: 2016-03-03 Last modified: 2017-06-12
Discussion:
The current TS doesn't support constrained constructors, since the matching form for constructor declarations in 12.1/1 doesn't have an optional requires clause.
This issue subsumed by issue 19.
Wording available: