cplusplus/concepts-ts

Technical Specification: Concepts

concepts-ts's Issues

production in [temp]

The production in [temp] says
template-declaration:
template < template-parameter-list > requires-clauseopt declaration
concept-introduction declaration
...

and the concept-introduction production is
concept-introduction:
concept-name { introduction-list } declaration

is one of those declarations redundant ?

[atomic.defns.atomic-constraint]

"A subexpression of a constraint that is not a logical-and-expression, logical-or-expression, or a subexpression of an atomic constraint."

1. "that" is unclear, it can be
   " a subexpression... that is not a logical-and-expression, logical-or-expression, or a subexpression of an atomic constraint"
   or
   "of a constraint that is not a logical-and-expression, logical-or-expression, or a subexpression of an atomic constraint"

2. what about cases when atomic constraint is the full constraint, i.e. it is not a subexpression of something else?

Editorial issues in clause 14

Find and remove appositive commas, so we don't break up the text. Also, change the use of the term "equivalent declaration" to "redeclaration. or something similar.

Update generic functions to match generic lambdas

I updated the wording for generic lambdas. Need to propagate similarities to generic functions.

Expression body does not declare a block scope

This probably isn't necessary since it a requires-body includes no declarations.

Concept introduction wording

The concept introduction wording (7/4) needs to get a lot clearer what the properties of the template-parameters so introduced are. "They match" is insufficient. At least, it's the "kind" (type, non-type, template), and a correspondence using the declaration order must be prescribed.

The wording does not currently define the order in which those template parameters are declared.

Update definition list

The definition list is incomplete and broken.

Template argument deduction examples

Add an example to template argument deduction (7.4.5.1).

Write an appendix describing compatibility issues

Potentially breaking changes with existing code.

"decl-sepcifier" misspelled

At https://github.com/cplusplus/concepts-ts/blob/master/dcl.dcl.html#L7

Partial specialization

Call out that constraints are checked when determining the partial ordering of class template specializations. Because constraints are checked during lookup and overload resolution, we're missing the check in this processing rule.

Address of overloaded function

In 13.4/4, eliminate candidates whose constraints are not satisfied.

Constraint association wording

In dcl.decl, p5 uses the old wording for constraint association.

Review the wording for associated constraints

It seems a bit off. Be clear that the we're talking about a single constraint expression that includes constraints introduced through requires-clauses and shorthand notation.

Explicit template specialization

Make sure there is wording for explicit template specializations.

template<typename T>
struct S {
  void f(int) requires C<T>;
};

template<>
void s<int>::f(int) { } // Valid iff C<int> is satisfied?

Check wording for non-member templates also.

requires clauses

A requires clause can be written as part of a function-definition and member-declarator. Add wording to this effect.

Partial specialization wording

temp.class.spec: Shouldn't we require some "subsumes" relationship for constraints on the template-parameters of partial specifications vs. the primary template?

Rewrite concept introductions

These should be a top-level declaration, not a sub-production of a template declaration.

requires-clause vs. requires-expression

I'm getting slightly confused between requires-clause and requires-expression; I think the two might be mixed up in a few places... Can you please check if the following sentences/productions should say 'requires-expression', and not 'requires-clause'?

5 Declarators
init-declarator:
declarator requires-clauseopt initializeropt

(and remaining of the chapter)

6 Templates
p1/2
in template-declaration:

6.1.3.1.1 p2 "A member function of a class template whose declarator contains a requires-clause is a constrained member function."

6.1.5 p2 "Constraint expressions are required after a requires-clause and in the body or initializer of a concept definition"

Constrained friends

6.4.2p10: "A constrained friend is a friend of a class template with associated constraints." This reads as if the enclosing class template needs to have associated constraints. This is probably not intended.

Declarators 5/p1

"A declarator declares a single variable, function, or type, within a declaration. The init-
declarator-list appearing in a declaration is a comma-separated sequence of declarators, each of which can have constraints or an initializer."

This suggests a declarator can have an initializer or constraints, but not both.

maybe:
"... each of which can have constraints and an initializer" (but i think this is not clear whether you need both if one is provided)
"... each of which has optional constraints and an optional initializer" (I like this, but I can not find many other constructs like this in the standard - not sure what core will say)

Constraints with nested name specifiers

When processing a nested name specifier, the constraints must match each scope exactly.

Typo in §7.4.1 2?

When a member of a constrained class template is defined outside of its class template
definition, it shall be specified with the template-parameters and associated constraints of the
lass template.

Don't use ellipses in requires

In expr.req.nested, don't elide requirements with ... This is explicitly called out as being ill-formed.

constrained type specifiers in compound requirements

In expr.req.compound reword p4... Switch the conditions around so that the affirmative comes first. Also, a conversion requirement is introduced when a constrained type specifier is present.

Be sure to catch all uses of constrained-type-name.

Typo

Typo in S7: 'Inscrutable' should be substituted for 'Mergeable' in the example in para4

Limit used of constrained-type-specifiers

Make it absolutely clear in 4.1.3 that a constrained type specifier can be used in only a subset of cases where auto can be used.

Typos

Sent by Roger Orr:

3.1.2.1p1
"Example: The following is requirement evaluates"
s/is //

3.1.2.1p2
"error: the valid expression well never be well-formed"
s/well/will/

3.1.2.4p1
"- an optional an exception constraint"
s/an exception/exception/

4.1.3p11
"Let C be a concept referred to by the concept-name. T be the constrained
type, and Args be a sequence of template arguments."
s/./,/

Constrained alias templates

A constrained alias templates constraints are not checked when the arguments are dependent. However, the alias is substituted at the point of use, before instantiation.

template<C T> using X = const T;

template<typename T>
void f(T x) {
  X<T> y = x; // Potentially ill-formed
}

There are several ways an implementer might be able to check constraints:

• Require that constrained alias templates not be substituted on use. This is probably a non-starter.
• Propagate the constraints as part of the resulting type, basically inventing a new kind of "constrained type" that is valid only if the constraints are satsifed
• Do not check the constraints

Morally, the alias should not be used if its constraints are not subsumed by the constraints of the surrounding context since instantiation could lead to substitution failures. This is effectively the same as separate checking, which is most definitely not required by concepts lite.

Overloading

Check the discussions of overloading in 8.3.5 and 13 to make sure that they are correct.

specify generic functions and generic lambdas in terms of placeholder type

btw,
7.1.6.4/ p2 says
"The auto and decltype(auto) type-specifiers designate a placeholder type that will be replaced later,"
, so constrained-name is also not a placeholder type.

[dcl.fct] /p3

"The associated constraints of the generic function are the conjunction of constraints introduced by the use of constrained-type-names in the parameter-declaration-clause. "

This does not mention the constraints introduced in the requires-clause

Illogical wording in [expr.prim.lambda]

The following text needs to be changed. But I do not know what is the intent.

  If the 
  <ins>The invented type <cxx-grammarterm>template-parameter</cxx-grammarterm>
  is a constrained parameter if the 

  If the <cxx-grammarterm>decl-specifier-seq</cxx-grammarterm> of the 
  corresponding <cxx-grammarterm>parameter-declaration</cxx-grammarterm> 
  includes a <cxx-grammarterm>constrained-type-specifier</cxx-grammarterm>,
  the invented type parameter is a 
  <cxx-grammarterm>constrained-parameter</cxx-grammarterm>, whose
  <cxx-grammarterm>constrained-type-specifier</cxx-grammarterm> matches
  that of the <cxx-grammarterm>parameter-declaration</cxx-grammarterm>.
  (<cxx-ref to="temp.param"></cxx-ref>).</ins>

Move definition of generic lambda into clause 5

Constrained friends example

6.4.2p10: "Constraints on non-template friend functions are written after the result type."
What does this mean? Your "operator==" in the example seems to violate that.

valid expression in compound expression

3.1.2.4/p3 says "The brace-enclosed expression in a compound-requirement introduces a valid expression constraint. "

so,

requires(Tx)
{
  {g(x)} noexcept ->T& #4
}

introduces a valid expression constraint on g(x) (and constant expression requirement, and conversion requirement). This is opposite to what we discussed earlier.

Either 3.1.2.4 needs to change or example explanation for 3,4,5,6 need to have a valid expression constraint in the explanations

Either

Update the HTML framework

Constraint checking is wrong

Move the constraint check wording from 6.1.3.4.1/2 to /5. That will cause constraint checks to occur after all arguments have been deduced against adjusted function parameter types.

Also, include wording that describes behavior for the case when a substitution failure occurs in the constraint expression.

constraint checking

... seems incorrect for class, alias, and variable templates. It does happen during name lookup, but the rules need to apply to class templates, alias templates, and variable templates.

Also, in name resolution, we need to define semantics for constraint checks on dependent arguments.

Default arguments in constrained type specifiers

I need wording to mandate the instantiation of default arguments in constrained specifiers for the purpose of making certain declarations equivalent in [dcl.fct].

Constrained friends clarification

All three examples in 6.4.2p10 show definitions of friends (btw, can you define
a friend struct like that?). How does declaration matching work for these
constrainted things? Does a constrained friend convey friendship to an unconstrained
function or type outside? Where is the specification that this doesn't work?

7.4.1.1/4 is redundant

Meaning is defined and examples are given in in 7.4.1.

Add editors marks

In [dcl.fct], for the refactoring of parameters into basic-parameters.

Constrained parameters

A constrained-type-specifier of a constrained type parameter shall not declare its parameter to be a cv-qualified type, reference type, or both.

template<typename T> concept bool C = ...;
template<const C& X> struct s; // Error

requires-clause is missing requires keyword

Unreferenced concepts

6.4.2p10: What is "shorthand"? What are "introduction"?

This is 7.4.3/2 in the new paper.

Abbreviated template declaration

From Roger Orr:

5.1.1p5 Introduces the phrase "abbreviated template declaration" without defining it.

Fix formatting in examples § 4.1.4 p 15

(All of) the examples in § 4.1.4, page 15 in the PDF file have odd indentation.

Template template arguments

Add a description of the example explaining why a more general template is valid argument, but a more constrained template is not.

dependent requirements

Make the target valid type and valid expression requirements be dependent types and dependent expressions.

Add a note explaining the restriction.