<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>P0396R0: C++ Concepts Active Issues List (Snapshot of Revision 4) </title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
</style>
</head>
<body>

<h1>C++ Concepts Active Issues List (Snapshot of Revision 4)</h1>
<table>
<tr>
  <td align="left">Document number: </td>
  <td align="left">P0396R0</td>
</tr>
<tr>
  <td align="left">Reply to:</td>
  <td align="left">Andrew Sutton &lt;<a href="mailto:asutton@uakron.edu">asutton@uakron.edu</a>&gt;</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2016-06-24</td>
</tr>
<tr>
  <td align="left">Audience:</td>
  <td align="left">CWG</td>
</tr>
</table>

  <p>Reference ISO/IEC TS 19217</p>

  <p>This document contains the C++ core language issues for the Concepts
  Technical specification which the Committee (INCITS PL22.16 + WG21) has not
  yet acted, that is, issues with status
  <a href="ts-active.html#Ready">Ready</a>,
  <a href="ts-active.html#TentativelyReady">Tentatively Ready</a>,
  <a href="ts-active.html#Review">Review</a>,
  <a href="ts-active.html#Drafting">Drafing</a>,
  <a href="ts-active.html#Open">Open</a>, and
  <a href="ts-active.html#New">New</a>.
  (See <a href="#Status">Issue Status</a> below).


  <p>This document is part of a group of related documents that together
  describe the issues that have been raised regarding the C++ Standard.
  The other documents in the group are:</p>
  <ul>
      <li><a href="ts-toc.html">Table of Contents</a> for all concepts issues.</li>
      <li><a href="ts-index.html">Index by Section</a> for all concepts issues.</li>
      <li><a href="ts-status.html">Index by Status</a> for all concepts issues.</li>
      <li><a href="ts-closed.html">Closed Issues List</a></li>
      <li><a href="ts-defect.html">Defect Reports List</a></li>
  </ul>

  <p>Section references in this document refelct the section numbering
  in document <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4549.pdf">
  WG21 N4549</a>.</p>

  <p>The purpose of these documents is to record the disposition of issues
  that have come before the Core Language Working Group of the ANSI
  (INCITS PL22.16) and ISO (WG21) C++ Standard Committee.</p>

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

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

  <p>Information regarding C++ standardization can be found at
  <a href="http://isocpp.org/std">http://isocpp.org/std</a>.


<h2>Revision History</h2>
<ul>
<li>R3: 2015-03-04 post-Jacksonville mailing<ul>
<li><b>Summary:</b><ul>
<li>28 open issues, up by 1.</li>
<li>7 closed issues, up by 1.</li>
<li>35 issues total, up by 2.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 2 New issues: <a href="ts-active.html#34">34</a>, <a href="ts-active.html#35">35</a>.</li>
<li>Changed the following issue from Open to New: <a href="ts-active.html#33">33</a>.</li>
</ul></li>
</ul>
</li>
</ul>

<h2><a name="Status"></a>Issue Status</h2>


  <p>Issues progress through various statuses as the Core Language Working Group
  and, ultimately, the full PL22.16 and WG21 committees deliberate and act. For
  ease of reference, issues are grouped in these documents by their status.
  Issues have one of the following statuses:</p>

  <p><b>Open</b>: The issue is new or the working group has not yet formed an
  opinion on the issue. If a Suggested Resolution is given, it reflects the
  opinion of the issue's submitter, not necessarily that of the working group
  or the Committee as a whole.</p>

  <p><b>Drafting</b>: Informal consensus has been reached in the working group
  and is described in rough terms in a Tentative Resolution, although precise
  wording for the change is not yet available.</p>

  <p><b>Review</b>: Exact wording of a Proposed Resolution is now available for
  an issue on which the working group previously reached informal consensus.</p>

  <p><b>Ready</b>: The working group has reached consensus that a change in the
  working draft is required, the Proposed Resolution is correct, and the issue
  is ready to forward to the full Committee for ratification.

  <p><b>Tentatively Ready</b>: Like "ready" except that the resolution was
  produced and approved by a subset of the working group membership between
  meetings. Persons not participating in these between-meeting activities are
  encouraged to review such resolutions carefully and to alert the working
  group with any problems that may be found.</p>

  <p><b>DR</b>: The full Committee has approved the item as a proposed defect
  report. The Proposed Resolution in an issue with this status reflects the
  best judgment of the Committee at this time regarding the action that will
  be taken to remedy the defect; however, the current wording of the Standard
  remains in effect until such time as a Technical Corrigendum or a revision
  of the Standard is issued by ISO.</p>

  <p><b>Dup</b>: The issue is identical to or a subset of another issue,
  identified in a Rationale statement.

  <p><b>NAD</b>: The working group has reached consensus that the issue is
  not a defect in the Standard. A Rationale statement describes the working
  group's reasoning.

  <p><b>Extension</b>: The working group has reached consensus that the issue
  is not a defect in the Standard but is a request for an extension to the
  language. The working group expresses no opinion on the merits of an issue
  with this status; however, the issue will be maintained on the list for
  possible future consideration as an extension proposal.

<h2>Active Issues</h2>
<hr>
<h3><a name="1"></a>1. Relationship of implicit conversion constraints to <tt>is_convertible</tt></h3>
<p><b>Section:</b> 14.10.1.1 [temp.constr.conv] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> CA <b>Opened:</b> 2015-05-18 <b>Last modified:</b> 2016-06-16</p>
<p><b>View all other</b> <a href="ts-index.html#temp.constr.conv">issues</a> in [temp.constr.conv].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
More a suggestion than a comment: would a convertible-to-type example
like the following be appropriate?

<pre>
<code>
template &lt;typename T&gt; concept bool D =
requires (T a) {
  { a } -&gt; int; // equivalent to std::is_convertible&lt;T,int&gt;::value ?
};
</code>
</pre>

It could be here or in 14.10.1.6, but I get the feeling it would follow the
<code>a==b</code> example  nicely. There is something similar in the  middle of the page,
with concept C2, but it is more involved and contributes something else to
reader comprehension.
</p>

During discussion in the July telecon, it was determined that there
is a CWG issue related to this request. In particular, it is not
obvious whether access checking was always applied or whether it
depending on the context in which the constraint was evaluated.
Unfortunately, the minutes did not capture which issue.





<hr>
<h3><a name="3"></a>3. Allow requires-expressions in more contexts</h3>
<p><b>Section:</b> 5.1.4 [expr.prim.req] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> US <b>Opened:</b> 2015-05-18 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#expr.prim.req">active issues</a> in [expr.prim.req].</p>
<p><b>View all other</b> <a href="ts-index.html#expr.prim.req">issues</a> in [expr.prim.req].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The following requirement seems overly restrictive, as it can be fairly
easily (but tediously) be worked around: "A <i>requires-expression</i> shall
appear only within a concept definition (7.1.7), or within the
<i>requires-clause</i> 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.)
</p>

<p>
Proposed change: Eliminate the requirement, thereby permitting
other uses for this new kind of expression of type <code>bool</code>. (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.)
</p>

<p>
There is a paper addressing the <i>requires-expression</i> portion of this
discussion.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0266r0.pdf"></a>.
</p>

<p>
Issue <a href="ts-active.html#29">29</a> was created to specifically address the inability to
evaluate concepts outside of SFINAE contexts.
</p>





<hr>
<h3><a name="6"></a>6. Simplify concept definitions</h3>
<p><b>Section:</b> 7.1.7 [dcl.spec.concept] <b>Status:</b> <a href="ts-active.html#EWG">EWG</a>
 <b>Submitter:</b> US <b>Opened:</b> 2015-05-18 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#dcl.spec.concept">active issues</a> in [dcl.spec.concept].</p>
<p><b>View all other</b> <a href="ts-index.html#dcl.spec.concept">issues</a> in [dcl.spec.concept].</p>
<p><b>View all issues with</b> <a href="ts-status.html#EWG">EWG</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Using <code>concept</code> as a <i>decl-specifer</i>, rather than forming a first class
entity like a type or template, makes the feature appear more complex than
it needs to be. Concepts would be simpler (for user and [we believe]
the specification) if there was only one kind, rather than both function
and variable syntax; the <code>bool</code> keyword would become redundant and the
set of restrictions on concepts based on them being functions or variables
would disappear.

We will provide a paper in time for the Lenexa pre meeting mailing
proposing a grammar that would give all concepts the form:

<pre>
<code>
    template &lt;typename T&gt;
    concept C = predicate;
</code>
</pre>
</p>

<p>
Also see issues <a href="ts-active.html#7">7</a> and <a href="ts-active.html#8">8</a> as they relate.
</p>

<p>
EWG is generally in favor of resolving this and related issues, but there
is no consensus on how to procdeed.
</p>





<hr>
<h3><a name="7"></a>7. Remove function concepts</h3>
<p><b>Section:</b> 7.1.7 [dcl.spec.concept] <b>Status:</b> <a href="ts-active.html#EWG">EWG</a>
 <b>Submitter:</b> US <b>Opened:</b> 2015-05-18 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#dcl.spec.concept">active issues</a> in [dcl.spec.concept].</p>
<p><b>View all other</b> <a href="ts-index.html#dcl.spec.concept">issues</a> in [dcl.spec.concept].</p>
<p><b>View all issues with</b> <a href="ts-status.html#EWG">EWG</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The syntactic distinction between a function concept  and a variable concept
seems to serve no useful  purpose. A single concept syntax seems sufficient,
and especially so once redundant elements are removed.

Merge the two concept forms into one, streamlining the syntax by eliminating
at least the following redundant elements: explicit bool (see comment below),
explicit return, and the always empty parentheses constituting the function
parameter list.
</p>

<p>
Also see issues <a href="ts-active.html#6">6</a> and <a href="ts-active.html#8">8</a> as they relate.
</p>

<p>
EWG is generally in favor of resolving this and related issues, but there
is no consensus on how to procdeed.
</p>





<hr>
<h3><a name="8"></a>8. Implicit bool for concepts</h3>
<p><b>Section:</b> 7.1.7 [dcl.spec.concept] <b>Status:</b> <a href="ts-active.html#EWG">EWG</a>
 <b>Submitter:</b> US <b>Opened:</b> 2015-05-18 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#dcl.spec.concept">active issues</a> in [dcl.spec.concept].</p>
<p><b>View all other</b> <a href="ts-index.html#dcl.spec.concept">issues</a> in [dcl.spec.concept].</p>
<p><b>View all issues with</b> <a href="ts-status.html#EWG">EWG</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Since a concept's type always must be <code>bool</code>, there seems little reason to
require the source code to say  so explicitly. Typing concept should be
sufficient without also typing bool immediately afterward.

Allow the compiler to supply bool (a) as the implicit return type for a
function concept and (b) as the implicit type for a variable concept. (Note:
this comment is implicitly accepted if issue <a href="ts-active.html#7">7</a> is accepted.)
</p>

<p>
Also see issues <a href="ts-active.html#6">6</a> and <a href="ts-active.html#7">7</a> as they relate.
</p>

<p>
EWG is generally in favor of resolving this and related issues, but there
is no consensus on how to procdeed.
</p>





<hr>
<h3><a name="11"></a>11. Concerns about subsumption and equivalence rules</h3>
<p><b>Section:</b> 14.10.2 [temp.constr.decl] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> US <b>Opened:</b> 2015-05-18 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#temp.constr.decl">active issues</a> in [temp.constr.decl].</p>
<p><b>View all other</b> <a href="ts-index.html#temp.constr.decl">issues</a> in [temp.constr.decl].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
We have a broad concern that it is hard to understand the feature purely
from the specification, especially the subsumption rules, and equivalence
rules to know when two signatures declare the same function or
are ambiguous equally constrained overloads, yet there is a lack of readily
available implementations to test our understanding against. While the feature
set of the TS looks good, we think one more iteration on the specification
would be useful.

Proposed solution: Recast the rules for subsumption as a mini grammar
(distinct from the C++ grammar) as the English text appears to be trying to
describe a grammar, but less formally, which leads to a potential lack of
precision, and more confusion for the reader. We are not highlighting specific
lack of precision at this time, as we have not emerged from confusion in
time to file appropriate comments.
</p>

<p>
EWG believes this is strictly a wording issue. Returned to CWG.
</p>






<hr>
<h3><a name="13"></a>13. Adjustment of parameter types in requires-expressions</h3>
<p><b>Section:</b> 5.1.4 [expr.prim.req] <b>Status:</b> <a href="ts-active.html#EWG">EWG</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2015-05-28 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#expr.prim.req">active issues</a> in [expr.prim.req].</p>
<p><b>View all other</b> <a href="ts-index.html#expr.prim.req">issues</a> in [expr.prim.req].</p>
<p><b>View all issues with</b> <a href="ts-status.html#EWG">EWG</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is unclear whether parameter types in a <i>requires-expression</i> are adjusted
in the same way that parameter types for functions are adjusted.
</p>

<p>
Andrew Sutton says that it should be the case.
</p>

<p>
The TS editor has moved the issue back to EWG for discussion. If requires-parameters
are adjusted in the same way that function parameters are adjusted, then we
lose information within the concept; top-level cv-qualifiers are removed,
types decay, etc. 
</p>



<p><b>Wording available:</b></p>
<p>
Add the following sentence to 5.1.4/5:

<blockquote>
<ins>The types of parameters declared in a <i>requires-expression</i> are adjusted
according to the rules for forming funcion types in 8.3.5.</ins>
</blockquote>
</p>





<hr>
<h3><a name="14"></a>14. Concept checks on template template parameters are too restrictive</h3>
<p><b>Section:</b> 14.4.3 [temp.arg.template] <b>Status:</b> <a href="ts-active.html#EWG">EWG</a>
 <b>Submitter:</b> Roland Bock <b>Opened:</b> 2015-10-02 <b>Last modified:</b> 2016-06-16</p>
<p><b>View all issues with</b> <a href="ts-status.html#EWG">EWG</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider a template that takes a <code>std::tuple</code> and copies its arguments
into another template (sink), see attached code.


<pre>
<code>
template&lt;typename Tuple, template&lt;typename...&gt; class Sink&gt;
using copy_tuple_args = ...
</code>
</pre>

The <code>copy_tuple_args</code> template is generic, not caring about the nature
of the copied arguments or the sink. This works fine as long as the
sink is not constrained, e.g. if the sink is another tuple. But a
constrained sink like  this

<pre>
<code>
template&lt;Column... C&gt;
struct column_list;
</code>
</pre>

is not allowed according to the working paper since it is more
constrained than the template parameter above. My <code>copy_tuple_arg</code>
template will suddenly cease to work when I start to use concepts.
</p>


<p><b>Wording available:</b></p>
<p>
Modify [temp.arg.template]:

<blockquote>
  A <i>template-argument</i> <ins>(call it A)</ins> matches a template
  <i>template-parameter</i> (call it P)
  when each of the template parameters in the <i>template-parameter-list</i> of the
  <i>template-argument</i>'s corresponding class template or alias template
  <del>(call it A)</del> matches the corresponding template parameter in the
  <i>template-parameter-list</i> of P, and P is <ins>either unconstrained or</ins>
  at least as constrained as A according to the rules in 14.10.3.
</blockquote>
</p>





<hr>
<h3><a name="15"></a>15. Partial specialization of non-concept variable template as a concept definition</h3>
<p><b>Section:</b> 7.1.7 [dcl.spec.concept] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2015-10-02 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#dcl.spec.concept">active issues</a> in [dcl.spec.concept].</p>
<p><b>View all other</b> <a href="ts-index.html#dcl.spec.concept">issues</a> in [dcl.spec.concept].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Partial specialization of a concept definition is prohibited by
7.1.7 [dcl.spec.concept]p7; however, there appears to be no
prohibition on a concept definition which is a partial specialization.

e.g.,

<pre>
<code>
template &lt;typename T, typename U&gt; bool C = true;
template &lt;typename U&gt; concept bool C&lt;int, U&gt; = false;
</code>
</pre>
</p>





<hr>
<h3><a name="16"></a>16. Concept and non-concept declarations of the same variable template</h3>
<p><b>Section:</b> 7.1.7 [dcl.spec.concept] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2015-07-09 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#dcl.spec.concept">active issues</a> in [dcl.spec.concept].</p>
<p><b>View all other</b> <a href="ts-index.html#dcl.spec.concept">issues</a> in [dcl.spec.concept].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It seems this is valid, and it is not clear if that is the intent.
<pre>
<code>
namespace A {
  template &lt;typename T&gt; extern const bool C;
};
template &lt;typename T&gt; concept bool A::C = true;
</code>
</pre>
</p>

<p>
Note: The C++14 restriction (removed in DR 1712) that the constexpr specifier be
present on every declaration of a variable template if any declaration has the
constexpr specifier applies to the "physical" presence of the specifier.
</p>

<p>
Note: The first declaration of A::C is not a "variable concept". There is no
restriction that a variable concept (i.e., "[a] variable template definition
having the concept specifier") is the only declaration of the entity that it
defines.
</p>

<p>
This seems to be a more general problem that being a "concept" is not a property
of the entity, but of its definition.
</p>

<p>
Andrew Sutton: This should not be a valid definition.
</p>





<hr>
<h3><a name="17"></a>17. Wording for subsumption</h3>
<p><b>Section:</b> 14.10.3 [temp.constr.order] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2015-05-25 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#temp.constr.order">active issues</a> in [temp.constr.order].</p>
<p><b>View all other</b> <a href="ts-index.html#temp.constr.order">issues</a> in [temp.constr.order].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The wording in N4377 subclause 14.10.3 [temp.constr.order] bullet 2.2 reads:
<ul>
<li>a disjunctive clause Pi subsumes a conjunctive clause Qj if and only if each atomic constraint in Pi subsumes any atomic constraint Qj, where</li>
<li>...</li>
</ul>
Firstly, as a conjunctive clause of a constraint in CNF, Qj may be a disjunction
as opposed to an atomic constraint. Adding "in" to give "any atomic constraint
in Qj" might be an editorial fix, but it does not fix the issue below.
</p>

<p>
Given "A and B" as P0, and "A" as Q0; then my reading of the "each subsumes any"
wording is that P0 subsumes Q0 if and only if each atomic constraint in P0 (that
is, A and B) subsumes A. That is: (A subsumes A) <i>and</i> (B subsumes A).
</p>

<p>
I believe the intent is that Pi subsumes Qj if and only if there exists an
atomic constraint, Pia, in Pi for which there exists an atomic constraint, Qjb,
in Qj such that Pia subsumes Qjb. I am not seeing a way to reconcile the current
wording of bullet 2.2 with what I believe the intent is.
</p>

<p>
Also see issue <a href="ts-active.html#30">30</a>. Addressing that issue will also close this one.
</p>






<hr>
<h3><a name="18"></a>18. Predicate constraints that are not constant expressions</h3>
<p><b>Section:</b> 7.1.7 [dcl.spec.concept] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2015-05-26 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#dcl.spec.concept">active issues</a> in [dcl.spec.concept].</p>
<p><b>View all other</b> <a href="ts-index.html#dcl.spec.concept">issues</a> in [dcl.spec.concept].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The word "constant" only appears once in normative text in N4377. It is unclear
to me whether a predicate constraint that is not a constant-expression is
ill-formed (which would require a diagnostic for a non-temploid function with a
requires-clause whose expression is not constant), or merely not satisfied.
</p>

<p>
It is useful to note that the "ill-formed" position leads to further issues
where constant-expressions of the form <code>P || Q</code> may be written such that
normalization of constraints will form <i>P or Q</i> where <i>Q</i> is a
predicate constraint whose expression is not a constant-expression.
</p>

<p>
Faisal Vali, Andrew Sutton, and Gabriel Dos Reis agree that
predicate constraints containing non-constant expressions should
be ill-formed.
</p>

<p>
Andrew Sutton suggests: If Q is not dependent and not a constant expression,
then the program would be ill-formed. Otherwise if, as a result of substituting
during satisfaction, Q is not a constant expression the program is
ill-formed.
</p>

<p>
However, if Q is dependent but never evaluated (because P is
satisfied), the program is well-formed. This would be the same if
substitution into Q would result in substitution failures (e.g., if Q
is <code>X&lt;T&gt;::value</code>).
</p>





<hr>
<h3><a name="19"></a>19. Wording makes all constrained function definitions ill-formed</h3>
<p><b>Section:</b> 8.4.1 [dcl.fct.def.general] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2015-06-04 <b>Last modified:</b> 2016-06-16</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In N4141 (C++14) subclause [dcl.fct.def.general] paragraph 2:
The declarator in a function-definition shall have the form

<blockquote>
<i>
  D1 ( parameter-declaration-clause ) cv-qualifier-seq<sub>opt</sub>
  ref-qualifier<sub>opt</sub>
  exception-specification<sub>opt</sub>
  attribute-specifier-seq<sub>opt</sub>
  trailing-return-type<sub>opt</sub>
</i>
</blockquote>
as described in 8.3.5. A function shall be defined only in namespace or class scope.
</p>

<p>
The issue also occurs in N4141 subclause 12.1 [class.ctor] paragraph 1 and
subclause 12.4 [class.dtor] paragraph 1.
</p>





<hr>
<h3><a name="20"></a>20. Concept-names and overload sets with non-concept functions</h3>
<p><b>Section:</b> 7.1.7 [dcl.spec.concept] <b>Status:</b> <a href="ts-active.html#EWG">EWG</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2015-06-12 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#dcl.spec.concept">active issues</a> in [dcl.spec.concept].</p>
<p><b>View all other</b> <a href="ts-index.html#dcl.spec.concept">issues</a> in [dcl.spec.concept].</p>
<p><b>View all issues with</b> <a href="ts-status.html#EWG">EWG</a> status.</p>
<p><b>Discussion:</b></p>
<p>
An identifier is a concept-name if it refers to a set of concept definitions (7.1.7).
Given the following, is C a concept-name?

<pre>
<code>
template &lt;typename T&gt; concept bool C() { return true; }
template &lt;typename T&gt; int C(T t) { return 42; }

struct A { };

bool operator &&(A, int (*)(int));
bool operator &&(A, bool);

bool f(A a) { return a && C&lt;int&gt;; }
</code>
</pre>

It seems that it is not a concept-name since it refers to a set of declarations
which does not contain only concept definitions. If that is the intent, it
should be made more clear.
</p>






<hr>
<h3><a name="21"></a>21. Disambiguation rules for <i>requires-clause</i>s</h3>
<p><b>Section:</b> 8.3.5 [dcl.fct] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2015-06-08 <b>Last modified:</b> 2016-06-16</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There is no disambiguation rule in C++14 PDTS 19217 which requires a
<i>type-specifier-seq</i> to consume as many <i>type-specifier</i>s as is
available and avoid backtracking.
</p>

<p>
Given either
<pre>
<code>
template &lt;typename T&gt; requires (bool)&T::operator short
unsigned int foo();
</code>
</pre>
or
<pre>
<code>
template &lt;typename T&gt; requires (bool)sizeof new (T::f()) short
unsigned int bar();
</code>
</pre>

there is more than one successful parse and it is unclear whether the return
type is <code>unsigned int</code> or <code>int</code>.
</p>

<p>
The after-the-function-declarator form of the <i>requires-clause</i> is also
ambiguous:

<pre>
<code>
struct X {};
template&lt;typename T&gt; void f() requires (bool)sizeof new X
{
  // might be the function body, might be a brace-or-equal-init for X
};
</code>
</pre>

A 'max munch' rule would probably do the wrong thing for the above case,
and likewise here:

<pre>
<code>
template&lt;typename T&gt; requires (bool)sizeof new unsigned
struct X { };
</code>
</pre>
</p>

<p>
Proposed resolutions have been to:
<ul>
  <li>require parens</li>,
  <li>specify rules to make this unambiguous</li>
  <li>specify the operand of a <i>requires-clause</i> as a new grammar.</li>
</ul>
No concensus has been reached.
</p>





<hr>
<h3><a name="22"></a>22. Initializers are never <i>constraint-expression</i>s</h3>
<p><b>Section:</b> 7.1.7 [dcl.spec.concept] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2015-06-19 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#dcl.spec.concept">active issues</a> in [dcl.spec.concept].</p>
<p><b>View all other</b> <a href="ts-index.html#dcl.spec.concept">issues</a> in [dcl.spec.concept].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Initializers [dcl.init] are not expressions. However bullet 6.3 in
[dcl.spec.concept] has a requirement where an "initializer shall be a
constraint-expression".
</p>

<p>
Presumably the constraint is that the initializer shall have exactly one full-
expression (that is,
<pre>
<code>
template &lt;typename T&gt; concept bool C{};
</code>
</pre>
is ill-formed), and that said full-expression is valid where a
<i>constraint-expression</i> is required.
</p>

<p>
It also seems that C++14 subclause 8.5 [dcl.init] paragraph 2 should be removed
or updated to exclude objects declared with the concept specifier in a manner
similar to how it excludes objects declared with the constexpr specifier.
</p>





<hr>
<h3><a name="23"></a>23. Associated constraints is a term defined for templates only</h3>
<p><b>Section:</b> 14.10.2 [temp.constr.decl] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2015-06-27 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#temp.constr.decl">active issues</a> in [temp.constr.decl].</p>
<p><b>View all other</b> <a href="ts-index.html#temp.constr.decl">issues</a> in [temp.constr.decl].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The definition of "associated constraints" is in 14.10.2 [temp.constr.decl]
paragraph 2 of N4377. Said definition only applies to templates, thus the
"associated constraints" being referred to by N4377 subclause 1.3.1
[defns.signature] appears to be undefined.
</p>





<hr>
<h3><a name="24"></a>24. Expression equivalence outside of declaration matching is novel</h3>
<p><b>Section:</b> 14.10.3 [temp.constr.order] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2015-06-27 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#temp.constr.order">active issues</a> in [temp.constr.order].</p>
<p><b>View all other</b> <a href="ts-index.html#temp.constr.order">issues</a> in [temp.constr.order].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider the following case:

<pre>
<code>
template &lt;typename T&gt; constexpr bool P = true;
constexpr bool Q = true;

template &lt;typename T = int&gt; requires P&lt;T&gt;
void foo(int = 0, T = 0);

template &lt;typename U = int&gt; requires P&lt;U&gt; && Q
void foo(U = 0, int = 0);

void bar() { foo(); }
</code>
</pre>

It seems that <code>&lt;T&gt;</code> in the first declaration of
<code>foo()</code> may be considered equivalent to P&lt;U&gt; in
the second declaration of <code>foo()</code>; however, I would find it surprising if the call
to <code>foo()</code> is unambiguous. Note that <code>T</code> and <code>U</code>
are not involved in the partial ordering in this case aside from the determination
of the more constrained template.
</p>






<hr>
<h3><a name="25"></a>25. Block scope template declarations</h3>
<p><b>Section:</b> 14.10.3 [temp.constr.order] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2015-06-03 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#temp.constr.order">active issues</a> in [temp.constr.order].</p>
<p><b>View all other</b> <a href="ts-index.html#temp.constr.order">issues</a> in [temp.constr.order].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The following constraint in Clause 14 [temp] is insufficient to prevent
the declaration of an abbreviated function template at block scope:

<blockquote>
A <i>template-declaration</i> can appear only as a namespace scope or class scope
declaration.
</blockquote>
</p>





<hr>
<h3><a name="26"></a>26. Function concepts not allowed to be declared in more than one TU</h3>
<p><b>Section:</b> 14.10.3 [temp.constr.order] <b>Status:</b> <a href="ts-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2015-06-09 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#temp.constr.order">active issues</a> in [temp.constr.order].</p>
<p><b>View all other</b> <a href="ts-index.html#temp.constr.order">issues</a> in [temp.constr.order].</p>
<p><b>Discussion:</b></p>
<p>
According to subclause 7.1.7 [dcl.spec.concept] paragraph 1:
<blockquote>
When a function is declared to be a concept, it shall be the only declaration
of that function.
</blockquote>
</p>


<p><b>Wording available:</b></p>
Change that sentence to read:
<blockquote>
When a function <ins>template</ins> is declared to be a concept, it shall be the only
declaration of that function <ins>template in the translation unit</ins>.
</blockquote>





<hr>
<h3><a name="27"></a>27. Redundant restriction on function specifiers for concepts</h3>
<p><b>Section:</b> 7.1.7 [dcl.spec.concept] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Nathan Wilson <b>Opened:</b> 2015-10-17 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#dcl.spec.concept">active issues</a> in [dcl.spec.concept].</p>
<p><b>View all other</b> <a href="ts-index.html#dcl.spec.concept">issues</a> in [dcl.spec.concept].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to subclause 7.1.7 [dcl.spec.concept] paragraph 5:

<blockquote>
A function concept has the following restrictions: (5.1):
<ul>
  <li>No function-specifiers shall appear in its declaration (7.1.2).</li>
  <li>...</li>
</ul>
</blockquote>

Would that be redundant because of the restriction on function-specifiers being
covered by subsection [dcl.spec.concept]p2 and the result of
[dcl.spec.concept]p1, specifically, "The concept specifier shall be applied
only to the definition of a function or variable template, declared in
namespace scope"?
</p>


<p><b>Wording available:</b></p>
Strike the first bullet in [dcl.spec.concept]p5.
<blockquote>
<ul>
  <li><del>No function-specifiers shall appear in its declaration (7.1.2).</del></li>
  <li>...</li>
</ul>
</blockquote>





<hr>
<h3><a name="28"></a>28. Ordering of constraints involving fold expressions</h3>
<p><b>Section:</b> 14.10.3 [temp.constr.order] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Robert Haberlach <b>Opened:</b> 2016-01-23 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#temp.constr.order">active issues</a> in [temp.constr.order].</p>
<p><b>View all other</b> <a href="ts-index.html#temp.constr.order">issues</a> in [temp.constr.order].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
Partial ordering by constraints doesn't regard fold expressions.

<code>
<pre>
template &lt;class T&gt; concept bool A = std::is_move_constructible&lt;T&gt;::value;
template &lt;class T&gt; concept bool B = std::is_copy_constructible&lt;T&gt;::value;
template &lt;class T&gt; concept bool C = A&lt;T&gt; &amp;&amp; B&lt;T&gt;;

template &lt;class... _tx&gt;
  requires (A&lt;_tx&gt; && ...)
void g(_tx... tx) {
  std::cout &lt;&lt; "a\n";
}

template &lt;class... _tx&gt;
  requires (C&lt;_tx&gt; && ...)
void g(_tx... tx) {
  std::cout &lt;&lt; "c\n";
}
</pre>
</code>

<p>
Andrew Sutton: this is logically valid and seems like a reasonable extension.
As a general rule, there may be many ways in which we can extend the constraint
language to support these kinds of resolutions. Of course, this means that
each such change potentially breaks changes.
</p>

<p>
This needs to apply to expansions of disjunctions also. This is done
by inverting the subsumption (i.e., when Q subsumes P).
</p>


<p><b>Wording available:</b></p>
Augment 14.10.3 [temp.constr.order]p(2.3) thusly:

an atomic constraint A subsumes another atomic constraint B if and only
if either <del>the</del> A and B are equivalent using the rules
described in 14.10.1 to compare constraints<ins>, or A is of the form
<tt>P && ...</tt> and B is of the form <tt>Q && ...</tt> or <tt>Q ||
...</tt>, where P subsumes Q.</ins>.





<hr>
<h3><a name="29"></a>29. Allow concepts to be evaluated in any context</h3>
<p><b>Section:</b> 14.10.2 [temp.constr.decl] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Andrew Sutton <b>Opened:</b> 2016-02-27 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#temp.constr.decl">active issues</a> in [temp.constr.decl].</p>
<p><b>View all other</b> <a href="ts-index.html#temp.constr.decl">issues</a> in [temp.constr.decl].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
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:

<code>
static_assert(C&lt;X&gt;(), ""); // for some concrete X
</code>
</p>

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

<p>
This issue is submitted as a result of an EWG straw poll taken during discussion
of issue <a href="ts-active.html#3">3</a>. 
</p>


<p><b>Wording available:</b></p>





<hr>
<h3><a name="30"></a>30. Normalization wording guarantees worst case performance for subsumption</h3>
<p><b>Section:</b> 14.10.2 [temp.constr.decl] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Andrew Sutton <b>Opened:</b> 2016-02-27 <b>Last modified:</b> 2016-06-16</p>
<p><b>View other</b> <a href="ts-index-open.html#temp.constr.decl">active issues</a> in [temp.constr.decl].</p>
<p><b>View all other</b> <a href="ts-index.html#temp.constr.decl">issues</a> in [temp.constr.decl].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current wording for normalization guarantees exponential performance
during subsumption.
</p>

<p>
Addressing this issue first requires that we address issue <a href="ts-active.html#29">29</a>.
If concepts can be safely evaluated in any context, then we do not need to
lift the entire constraint into the current instantiation.
</p>

<p>
The current phrasing also prohibits certain compiler optimizations by requiring
a full expansion to atomic constraints. In particular, this does not admit
early termination of the algorithm or memoization of comparisons.
</p>

<p>
Prior to the Skillman concepts meeting, there was a much more abstract wording
for the subsumption algorithm. One resolution would be to revert the current
wording to the older version.
</p>


<p><b>Wording available:</b></p>





<hr>
<h3><a name="31"></a>31. Constrained-type-specifiers introduce non-type placeholders</h3>
<p><b>Section:</b> 7.1.6.4.2 [dcl.spec.auto.constr] <b>Status:</b> <a href="ts-active.html#Open">Open</a>
 <b>Submitter:</b> Jason Merrill <b>Opened:</b> 2016-03-03 <b>Last modified:</b> 2016-06-19</p>
<p><b>View all other</b> <a href="ts-index.html#dcl.spec.auto.constr">issues</a> in [dcl.spec.auto.constr].</p>
<p><b>View all issues with</b> <a href="ts-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
A <i>constrained-type-specifier</i> also denotes non-type constraints. The
production name should reflect that.
</p>





<hr>
<h3><a name="33"></a>33. Undefined behavior of <i>partial-concept-id</i>s in <i>template-introductions</i></h3>
<p><b>Section:</b> 14.2 [temp.intro] <b>Status:</b> <a href="ts-active.html#New">New</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2016-05-04 <b>Last modified:</b> 2016-06-19</p>
<p><b>View all issues with</b> <a href="ts-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There appear to be no semantics applied to the use of a partial-concept-id as
the qualified-concept-name in a template-introduction. In particular, N4552
subclause 14.2 [temp.intro] refers to subclause 14.10.4 [temp.constr.resolve],
which in turn does not specify what the concept argument list is in such a case.
</p> 

<p>
Andrew Sutton: "disallowing this seems reasonable".
</p>


<p><b>Wording available:</b></p>
<p>
</p>





<hr>
<h3><a name="34"></a>34. Premature substitution into associated constraints</h3>
<p><b>Section:</b> 14.6.4 [temp.friend] <b>Status:</b> <a href="ts-active.html#New">New</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2016-05-06 <b>Last modified:</b> 2016-06-19</p>
<p><b>View all issues with</b> <a href="ts-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Given:

<pre>
<code>
template &lt;typename T&gt;
    requires true || T::happy
void foo(T &amp;&amp;) { }

template &lt;typename T&gt;
struct A {
  friend void bar(A &amp;&amp;)
      requires true || T::happy {
  }
};

int main(void) {
  foo(0);
  bar(A&lt;int&gt;());
}
</code>
</pre>

there appears to be wording (normative and otherwise), which would render the
program ill-formed. I assume that is not the intent.
</p>

<p>
The wording involved is as follows: N4553 subclause 14.6.4 [temp.friend]
paragraph 11: In the instantiation of such a class template (14.8), the template
arguments are substituted into the constraints but not evaluated. [ ... ] If
substitution fails, the program is ill-formed.
</p>

<p>
N4553 subclause 14.9.2 [temp.deduct] paragraph 5: If the function template has
associated constraints (14.10.2), the template arguments are substituted into
the associated constraints without evaluating the resulting expression. If this
substitution results in an invalid type or expression, type deduction fails.
</p> 


<p><b>Wording available:</b></p>
<p>
</p>





<hr>
<h3><a name="35"></a>35. Handwaving around instantiation of constraining elements</h3>
<p><b>Section:</b> 14.10.1 [temp.constr.constr] <b>Status:</b> <a href="ts-active.html#New">New</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2016-05-06 <b>Last modified:</b> 2016-06-19</p>
<p><b>View all issues with</b> <a href="ts-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>

The TS often refers to substitution or instantiation of associated constraints;
however, associated constraints are a derived property of what might be called
"constraining elements", i.e., constrained-type-specifiers, constrained-
parameters, template-introductions and constraint-expressions.

It appears that the wording in N4553 subclause 14.10.1 [temp.constr.constr]
is attempting to achieve "partial substitution" is trumped in many cases by
substitution into constraining elements.

For example, the associated constraints would evaluate false (or in a more
realistic case, a check that <code>T::type</code> is a type) prior to 
considering <code>C&lt;placeholder, typename T::type&gt;()</code>, but it is unclear 
whether instantiating <code>A&lt;int&gt;</code> causes an error from the use of 
<code>T::type</code>:

<pre>
<code>
template &lt;typename T, typename U&gt;
concept bool C() { return true; }

template &lt;typename T&gt;
struct A {
  template &lt;typename U&gt; requires false
  void foo(C&lt;typename T::type&gt;) { }
};

int main(void) { A&lt;int&gt; a; }
</code>
</pre>

</p> 


<p><b>Wording available:</b></p>
<p>
</p>





</body>
</html>
