Good thoughts.


> And I'm concerned about implicitly treating both ranges and packs the
> same. I think this could run into similar issues as we saw with expansion
> statements, and similar issues to the case I talk about in P1858 (the
> context here was directly expanding a tuple into its underlying parts,
> which is similar to expanding a range of meta::infos into its infos):
>
> template <typename T, typename... U>void call_f(T t, U... us){ // Is this intended to add 't' to each element in 'us' // or is intended to pairwise sum the tuple 't' and // the pack 'us'? f((t + us)...);}
>
> Here, it's easy for me to come up with examples of wanting either choice:
> * call_f(tuple(1, 2), 3, 4) could be intended to call f(4, 6), doing the
> pairwise sum.
> * call_f(point{1, 2}, point{0, 1}, point{3, 7}) could be intended to call
> f(point{1,3}, point{4,9}), adding 't' to each element.
>

I think the issues expanding ranges are a little different than with the
issues in the original expansion statements. I also think the expansion
here is perfectly clear (for some definition of perfect and clear). It's
always the 2nd behavior.

See my other post. If you wanted the first result, you would need to
nominate t as being expandable:

    f((...t + us)...);


A similar thing could come up here - where we have a range of meta::info
> and a pack and may want to expand the range and may not want to:
>
> template <typename E, typename... Args>
> void foo(Args... args) {
> constexpr auto enums = meta::enumerators_of(reflexpr(E));
> g(|impl(enums, args)|...);
> }
> enum E { A, B, C };
> void bar() {
> foo<E>(1, 2, 3);
> }
>
> Are we calling impl(enums, 1) or are we calling impl(reflexpr(E::A), 1)?
>

The former. Writing this:

    g(|impl(...enums, args)|...);

would give you a splice with 2 unexpanded packs (enums) and args and you'd
get:

impl(^A, ^B, ^C, 1, 2, 3);

 Andrew