> | Previous discussion seemed to indicate that saving constraints with
> | template decls was preferable.
>
> Yes; exactly.
>
> | The committed version in the branch carries those constraints in
> | template_info for the temploid.
>
> Yes; I think that is good.
So we should associate constraints with both TEMPLATE_DECLs and TEMPLATE_INFOs?
Storing constraints with TEMPLATE_INFO could require more memory since
each instantiation generates a new one. It doesn't look like that
structure has any free trees anyways, so we'd have to add a field
(which is what we've done now).
Concepts lite shouldn't need to track instantiated constraints,
anyway. Constraints are either satisfied or they aren't.
> | > I think we need to remember them for duplicate_decls or other routines
> | > that either check or use ODR-derived properties.
> |
> | This doesn't seem to be a problem. IIRC, the instantiated declarations
> | are differentiated by their template constraints, not their
> | instantiated constraints.
> |
> | Differentiating by instantiated constraints may not be viable,
> | anyways. Especially, if the instantiation folds them to only "true" or
> | "false".
>
> Hmm, I am lost here. Could you clarify with examples?
template<typename T>
struct S {
void f() requires Input_iterator<T> { }
void f() requires Bidirectional_iterator<T> { }
};
Probably an unlikely example, but anyways...
The class S<T> has two declarations of f, "S<T>::f() requires
Input_iterator<T>" and "S<T>::f() requires Bidirectional_iterator<T>".
When you instantiate S, say S<int*>, we instantiate the nested
declarations. They are made distinct on the basis of the dependent
constrains. If you try to distinguish them on the basis of their
instantiated constraints you could have:
template<>
struct S<int*> {
void f() requires true;
void f() requires true; // Oops. Not desirable.
};
Andrew
