cplusplus / concepts-ts Goto Github PK
View Code? Open in Web Editor NEWTechnical Specification: Concepts
Technical Specification: Concepts
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.
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.
6.4.2p10: What is "shorthand"? What are "introduction"?
This is 7.4.3/2 in the new paper.
In expr.req.nested, don't elide requirements with ... This is explicitly called out as being ill-formed.
These should be a top-level declaration, not a sub-production of a template declaration.
A requires clause can be written as part of a function-definition and member-declarator. Add wording to this effect.
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
"A subexpression of a constraint that is not a logical-and-expression, logical-or-expression, or a subexpression of an atomic constraint."
"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"
what about cases when atomic constraint is the full constraint, i.e. it is not a subexpression of something else?
"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
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.
(All of) the examples in § 4.1.4, page 15 in the PDF file have odd indentation.
In 13.4/4, eliminate candidates whose constraints are not satisfied.
Check the discussions of overloading in 8.3.5 and 13 to make sure that they are correct.
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/./,/
temp.class.spec: Shouldn't we require some "subsumes" relationship for constraints on the template-parameters of partial specifications vs. the primary template?
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.
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.
The definition list is incomplete and broken.
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.
In dcl.decl, p5 uses the old wording for constraint association.
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.
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.
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:
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.
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.
I updated the wording for generic lambdas. Need to propagate similarities to generic functions.
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.
In [dcl.fct], for the refactoring of parameters into basic-parameters.
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"
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.
"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)
Make the target valid type and valid expression requirements be dependent types and dependent expressions.
Add a note explaining the restriction.
When processing a nested name specifier, the constraints must match each scope exactly.
... 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.
I need wording to mandate the instantiation of default arguments in constrained specifiers for the purpose of making certain declarations equivalent in [dcl.fct].
Meaning is defined and examples are given in in 7.4.1.
Add a description of the example explaining why a more general template is valid argument, but a more constrained template is not.
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 ?
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.
Add an example to template argument deduction (7.4.5.1).
This probably isn't necessary since it a requires-body includes no declarations.
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?
Typo in S7: 'Inscrutable' should be substituted for 'Mergeable' in the example in para4
Potentially breaking changes with existing code.
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
From Roger Orr:
5.1.1p5 Introduces the phrase "abbreviated template declaration" without defining it.
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>
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.