This paper deals with some small-ish fallout parts of the merge of Concepts into the C++20 working draft; namely, requires-clauses in lambdas, auto as a function parameter type, and requires-clauses in template template parameters.
Currently, lambdas cannot have requires-clauses. One of the arguments for that lack I've heard mentioned is that lambdas are supposed to be short, and requires-clauses make lambdas verbose.
The problem with that argument is that it focuses on the wrong thing; it's, at least to me, much more important that lambdas can be
I don't think that's just a consistency issue. I envision writing implementation-detail function templates with requires-clauses rather than proper Concepts when such a Concept is not all that reusable. I will choose to not write a Concept because it's not going to be a cross-cutting Domain Concept, it's just a simple compile-time contract of a function. For such uses, the scope of that contract should be allowed to be as narrow as feasible, and it should not be forced to be any wider than the scope of the function parameter declaration.
We happily allow auto as a lambda parameter type, in which case the lambda is polymorphic. We currently don't allow a plain function to have auto as a parameter type.
This, again, hurts refactoring. There's also no ambiguity about whether such a function is a template, it's obviously a template, its parameter type is a keyword that suggests the type can be anything, and that the type is deduced.
I'm perfectly willing to admit that this is not a real functionality gap. I can write an unconstrained template instead of a function with an auto parameter. The problem there is that none of the arguments against a terse syntax for a constrained function template hold, and now I need to do tedious mechanical transformations when doing a simple refactoring from a polymorphic lambda to a function template. Sure, for lambdas that capture something, there is a fair amount of additional mechanical transformation involved, but for non-capturing lambdas there shouldn't be.
Curiously, our specification doesn't allow requires-clauses in template template parameters, but the gcc implementation of the Concepts TS does.
Again, in order to constrain a template template parameter without having to write a namespace-scope concept definition, we need to support a requires-clause here. Not every constraint should be a concept.
From practical adoption experience, I deem it very likely that the first step in moving from existing constraints to concepts is to turn enable_ifs into requires-clauses. That's to me a very good reason to not leave gaps in our support for requires-clauses.
There's a perhaps more controversial and a much scarier aspect to it. Some codebases will need to try and make pre-C++20 and C++20 constraints look the same on the declaration level. This will mean that macros get employed, but those macros can't work if there's no syntactic position that works for an enable_if and a requires-clause. The pre-C++20 constraints can't use the syntactic position for a constrained-template-parameter, but they can use the syntactic position for a requires-clause.
[](tuple<Args1...>, tuple<Args2...>) requires (PackRelation<Args1, Args2> &&...)