On Wed, 23 Oct 2024, Jason Merrill wrote: > On 10/23/24 10:20 AM, Patrick Palka wrote: > > On Tue, 22 Oct 2024, Marek Polacek wrote: > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > -- >8 -- > > > This patch implements C++26 Pack Indexing, as described in > > > <https://wg21.link/P2662R3>. > > > > > > The issue discussing how to mangle pack indexes has not been resolved > > > yet <https://github.com/itanium-cxx-abi/cxx-abi/issues/175> and I've > > > made no attempt to address it so far. > > > > > > Rather than introducing a new template code for a pack indexing, I'm > > > adding a new operand to EXPR_PACK_EXPANSION to store the index; for > > > TYPE_PACK_EXPANSION, I'm stashing the index into TYPE_VALUES_RAW. This > > > > What are the pros and cons of reusing TYPE/EXPR_PACK_EXPANSION instead > > of creating two new tree codes for these operators (one of whose > > operands would itself be a bare TYPE/EXPR_PACK_EXPANSION)? > > > > I feel a little iffy at first glance about reusing these tree codes > > since it muddles what "kind" of tree they are: currently they represent > > a _vector_ or types/exprs (which is reflected by their tcc_exceptional > > class), and with this approach they can now also represent a single > > type/expr (despite their tcc_exceptional class), depending on whether > > PACK_EXPANSION_INDEX is set.
Oops, I just noticed that TYPE/EXPR_PACK_EXPANSION are tcc_type/expr rather than tcc_exceptional, somewhat surprisingly. I must've been thinking about ARGUMENT_PACK_SELECT which is tcc_exceptional. But I guess conceptually they still represent a vector of types/exprs rather than a single type/expr currently. > > Yeah, I made a similar comment. FWIW there's an interesting example mentioned in https://github.com/itanium-cxx-abi/cxx-abi/issues/175: template <class... T> struct tuple { template <unsigned I> T...[I] get(); }; tuple<int, char, bool> t; How should we represent the partial instantiation of T...[I] with T={int, char, bool}? IIUC with the current approach we could use PACK_EXPANSION_EXTRA_ARGS to defer expansion until the index is known. With new tree codes, e.g. PACK_INDEX_EXPR/TYPE, if we represent the pack/pattern itself as a *_PACK_EXPANSION operand we could just expand that immediately, yielding a TREE_VEC operand. (And this expansion shouldn't allocate due to the T... optimization in tsubst_pack_expansion.) > > > At the same time, the pattern of a generic *_PACK_EXPANSION can be > > anything whereas for these index operators we know it's always a single > > bare pack, so we also don't need the full expressivity of > > *_PACK_EXPANSION to represent these operators either. > > I imagine that someone will want to extend it to indexing into an arbitrary > pack expansion before long, so I wouldn't try too hard to simplify based on > that assumption. > > Jason > >
