<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 10, 2018 at 4:29 PM, Saar Raz <span dir="ltr"><<a href="mailto:saar@raz.email" target="_blank">saar@raz.email</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Tue, Jul 10, 2018 at 4:40 PM Hubert Tong <<a href="mailto:hubert.reinterpretcast@gmail.com" target="_blank">hubert.reinterpretcast@gmail.<wbr>com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I believe for the similar case of "auto" variables, we produce the template parameter list on the stack.<br></div></div></div></div></blockquote></span><div>With compound requirements, you have a complete abstract-declarator as part of the deduced-against types, which can reference the template parameter in all manner of ways. That's what led me to store the template parameter list - do you see a specific problem with storing it?</div></div></div>
</blockquote></div>I don't see a problem with storing it other than the usual concerns around memory usage. The template parameter list is an artifact that is mainly useful for performing the deduction, but the deduction is not likely to occur with every instance of the "same" <i>requires-expression</i>. The information for the <i>return-type-requirement</i> can be stored as a type. This is straightforward for the <i>trailing-return-type</i> case. For the latter case, I think it is not a stretch to implement a derived class of clang::DeducedType that represents a constrained placeholder type.<br></div></div>