On Tue, Nov 5, 2019 at 2:42 PM Jeff Chapman <jchap...@lock3software.com> wrote:
>
> 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.
We track other substitution cases as part of the template
instantiation depth limit, notably instantiating the
noexcept-specifier. This seems like a similar situation.
Jason
