t; > > > > > > > semi-consistency
> > > > > > > > > with Clang seems like a reasonable argument in favour of
> > > > > > > > > keeping
> > > > > > > > > the
> > > > > > > > > name. I'd be op
ead of
TREE_LIST at once in a followup patch.
Bootstrapped and regtested 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]
> > > > 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
#x27;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++: Define built-in for std::tuple_e
; > > > 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 fronte
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 new built-in to replace the recursive class template
in
; > 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 terms of TRAIT_TYPE, names it __type_pack_eleme
;
> > Btw the 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 impleme
ait.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 __builtin_type_pack_element, and treats invocations of it
like a template-id instead of a call (to match Clang).
-- >8 --
Su
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. __builtin_type
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 fr
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, int
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. __builtin
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 examp
14 matches
Mail list logo
