On 2/20/23 11:58, Patrick Palka wrote:
> On Sat, 18 Feb 2023, Jason Merrill via Gcc-patches wrote:
> 
>> Tested x86_64-pc-linux-gnu.  Since this is fixing experimental (C++20)
>> functionality, I think it's reasonable to apply now; I'm interested in other
>> opinions, and thoughts about the user-facing functionality.  I'm thinking to
>> make it internal-only for GCC 13 at least by adding a space in the name, but
>> does this look useful to the library?
> 
> IIUC this looks like a generalization of an __is_specialization_of trait
> that returns whether a type is a specialization of a given class template,
> which seems potentially useful for the library to me.  We already define
> some ad-hoc predicates for testing this, e.g. __is_reverse_view,
> __is_span etc in <ranges> as well as a more general __is_specialization_of
> in <format> for templates that take only type arguments.  Using a built-in
> trait should be more efficient.
> 
>[...]
> 
> Since the first argument of a TRAIT_EXPR can now be a TEMPLATE_DECL, I
> suppose cp_tree_equal needs to be changed too.
>
 >[...]
> 
> For sake of the __is_specialization_of use case, I wonder if it'd
> be possible to have a "fast path" that avoids deduction/coercion when
> the given template is a class template?

Thanks, done.  I've also fixed array bounds type deduction and added 
more comments about the relationship of the implementation and the 
specification in terms of partial specialization.

The second patch makes it internal-only for GCC 13; you can revert that 
if you want to experiment with using it in the library.

Tested x86_64-pc-linux-gnu, applying to trunk.