Date: Sun, 23 Jan 2022 10:32:16 -0500
So, let me make sure I understand the proposal.
Now, recall for the moment that this:
```
template<ConceptName T>
void foo();
```
Is (nearly) exactly equivalent to this:
```
template<typename T>
requires ConceptName<T>
void foo();
```
So your feature must apply to `requires` clauses of arbitrary complexity.
So, to implement this pure-convenience feature, compilers must:
1. For any given concept, scan it for `requires` expressions. If it
has any, extract from those expressions any `typename` checks and
associate them with template parameters for the concept. This must be
done recursively. Also, as mentioned by `Avi`, something has to be
done about disjunction expressions.
2. When a constrained template header is compiled, list all of the
template parameters and the concepts they are required to follow.
Extract from these concepts the aforementioned list of `typename`
patterns, relating them to the parameters to the current template.
3. When the constrained template itself is compiled, if any particular
dependent name matches one of the `typename` patterns, then it is
*grammatically* assumed to be a `typename`.
This is a Herculean amount of effort... all so that you can avoid
typing `typename` *sometimes*.
Now, recall for the moment that this:
```
template<ConceptName T>
void foo();
```
Is (nearly) exactly equivalent to this:
```
template<typename T>
requires ConceptName<T>
void foo();
```
So your feature must apply to `requires` clauses of arbitrary complexity.
So, to implement this pure-convenience feature, compilers must:
1. For any given concept, scan it for `requires` expressions. If it
has any, extract from those expressions any `typename` checks and
associate them with template parameters for the concept. This must be
done recursively. Also, as mentioned by `Avi`, something has to be
done about disjunction expressions.
2. When a constrained template header is compiled, list all of the
template parameters and the concepts they are required to follow.
Extract from these concepts the aforementioned list of `typename`
patterns, relating them to the parameters to the current template.
3. When the constrained template itself is compiled, if any particular
dependent name matches one of the `typename` patterns, then it is
*grammatically* assumed to be a `typename`.
This is a Herculean amount of effort... all so that you can avoid
typing `typename` *sometimes*.
Received on 2022-01-23 15:32:30