================
@@ -309,7 +309,10 @@ enum BuiltinTemplateKind : int {
BTK__make_integer_seq,
/// This names the __type_pack_element BuiltinTemplateDecl.
- BTK__type_pack_element
+ BTK__type_pack_element,
+
+ /// This names the __type_list_dedup BuiltinTemplateDecl.
+ BTK__type_list_dedup,
----------------
zygoloid wrote:
Given that we already have builtin templates, if we're concerned about the
boilerplate involved in adding a new one, perhaps we could remove most of that
boilerplate instead? It looks like an xmacro (`.def` file) approach could
handle most of these changes. Though I'd suggest we decouple that refactoring
from this change.
Unless we think that builtin templates were a mistake, and we instead would
prefer to deprecate and eventually remove our support for builtin templates?
For what it's worth, as I recall the idea was that builtin templates would be a
lot *less* invasive than builtin type traits for this kind of thing. They don't
need a new keyword, separate parsing rules, a new AST representation, etc --
they're just another kind of type template name. And they support type
arguments, non-type arguments, and templates as arguments without extra work.
And they can reuse our normal type-checking for templates. The big downside is
that they don't work in C, but for things intended for operating on parameter
packs such as the existing two builtin templates and this new one, that's fine.
https://github.com/llvm/llvm-project/pull/106730
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
