t; > > > > semi-consistency
> > > > > > > > > with Clang seems like a reasonable argument in favour of
> > > > > > > > > keeping
> > > > > > > > > the
> > > > > > > > > name. I'd be open to alternativ
ted on x86_64-pc-linux-gnu, also tested against
libc++'s tuple/variant impl for good measure (which uses
__type_pack_element when available).
-- >8 --
Subject: [PATCH] c++: Define built-in for std::tuple_element [PR100157]
This adds a new built-in to replace the recursive class template
insta
; > > name. I'd be open to alternative names though, e.g.
> > > > > > > __builtin_nth_type
> > > > > > > or __builtin_type_at_index.
> > > > > >
> > > > > > Rather than giving the trait a different name from
> > > > &g
lements
the built-in in terms of TRAIT_TYPE, names it __type_pack_element
instead of __builtin_type_pack_element, and treats invocations of it
like a template-id instead of a call (to match Clang).
-- >8 --
Subject: [PATCH] c++: Define built-in for std::tuple_element [PR100157]
This adds a
t; Rather than giving the trait a different name from __type_pack_element,
> > > > I wonder if we could just special case cp_parser_trait to expect <>
> > > > instead of parens for this trait?
> > > >
> > > > Btw the frontend recently got a ge
instead of __builtin_type_pack_element, and treats invocations of it
like a template-id instead of a call (to match Clang).
-- >8 --
Subject: [PATCH] c++: Define built-in for std::tuple_element [PR100157]
This adds a new built-in to replace the recursive class template
instantiations done by traits su
much of the boilerplate of adding a new type-yielding built-in
> > > trait, see e.g. cp-trait.def.
> >
> > Here's a tested patch based on Jonathan's original patch that implements
> > the built-in in terms of TRAIT_TYPE, names it __type_pack_element
> > instead of __
frontend recently got a generic TRAIT_TYPE tree code, which gets
> > rid of much of the boilerplate of adding a new type-yielding built-in
> > trait, see e.g. cp-trait.def.
>
> Here's a tested patch based on Jonathan's original patch that implements
> the built-in in
a tested patch based on Jonathan's original patch that implements
the built-in in terms of TRAIT_TYPE, names it __type_pack_element
instead of __builtin_type_pack_element, and treats invocations of it
like a template-id instead of a call (to match Clang).
-- >8 --
Subject: [PATCH] c++: Defi
On Thu, 7 Jul 2022, Jonathan Wakely via Gcc-patches wrote:
> This adds a new built-in to replace the recursive class template
> instantiations done by traits such as std::tuple_element and
> std::variant_alternative. The purpose is to select the Nth type from a
> list of types, e.g.
On Thu, 7 Jul 2022 at 20:29, Jason Merrill wrote:
>
> On 7/7/22 13:14, Jonathan Wakely wrote:
> > This adds a new built-in to replace the recursive class template
> > instantiations done by traits such as std::tuple_element and
> > std::variant_alternative. The purpose is to select the Nth type
On 7/7/22 13:14, Jonathan Wakely wrote:
This adds a new built-in to replace the recursive class template
instantiations done by traits such as std::tuple_element and
std::variant_alternative. The purpose is to select the Nth type from a
list of types, e.g. __builtin_type_pack_element(1, char,
On Thu, Jul 07, 2022 at 06:14:36PM +0100, Jonathan Wakely wrote:
> This adds a new built-in to replace the recursive class template
> instantiations done by traits such as std::tuple_element and
> std::variant_alternative. The purpose is to select the Nth type from a
> list of types, e.g.
This adds a new built-in to replace the recursive class template
instantiations done by traits such as std::tuple_element and
std::variant_alternative. The purpose is to select the Nth type from a
list of types, e.g. __builtin_type_pack_element(1, char, int, float) is
int.
For a pathological
14 matches
Mail list logo
