On Thu, Oct 31, 2019 at 8:03 AM Nathan Sidwell wrote:
> Why doesn't the std specify the satisfaction nesting limit in the same
> way as template instantiation? (at least that's what I infer from your
> question).
I'm not sure why it's not explicitly listed along with the template
instantiation limit ([implimits]/2.41). Perhaps it's something that
should be added? It does seem like a distinct limit since satisfaction
can occur recursively without having more than one template
instantiation in the call stack at any given time. To give an example:
template<int N = 1, typename T = int>
requires requires(T t) { foo<N + 1>(t); }
void foo(T t) { }
A call to foo<1>(1) results in unbounded call stack like:
resolve foo<1>(int)
instantiate the decl of foo<1>(int)
check if foo<1>(int) satisfies its constraints
resolve foo<2>(int)
instantiate the decl of foo<2>(int)
check if foo<2>(int) satisfies its constraints
...
Per [temp.inst]/17 "the type-constraints and requires-clause of a
template specialization or member function are not instantiated along
with the specialization or function itself" so instantiating the decl
of foo<1>(int) does not depend on the instantiation of any other
template and the template instantiation depth is only incremented once
before decremented when control flow returns to overload resolution.
This needs to be resolved someway, but reusing the template
instantiation depth limit would be an odd choice since there are no
recursive template instantiations in the process. A parallel
-fsatisfaction-depth= limit and associated diagnostics seems like a
better way to resolve this issue.
Does this seem like a good way forward?
Thanks,
