Abstract

We propose homogeneous function parameter packs for C++29: a variable number of parameters of one declared type. One declaration replaces fixed-arity overload families, retaining ordinary parameter initialization, conversion ranking, and a compile-time count.

We ask the Evolution Working Group to first confirm the C++29 pairing of named and unnamed packs with mandatory C-varargs commas and reclamation of the comma-less spelling. This gives packs the same meaning with or without a name, while changing declarations deprecated in C++26.

1 Revision history

1.1 R3 (2026-10-22)

• Updated active contributors and credited James Touton as original author.
• Retargeted to C++29 and rebased wording on the current working draft.
• Replaced the separate pack-length component of specialization identity with an invented constant template parameter for the count.
• Added Abseil and CasADi comparisons with current C++ alternatives.
• Updated classification, deduction, initialization, address-taking, and lambda rules for the count model and C++26 pack indexing.
• Required mandatory C-varargs commas and reclamation of the comma-less spelling for unnamed packs in C++29.

1.2 R2 (2019-10-05)

• Rebased wording against N4830.
• Discussed the impact of mandatory varargs commas.

1.3 R1 (2019-03-11)

• Rebased wording against N4800 and added signature changes.
• Removed permission for empty template parameter lists in template declarations.
• Added a feature test macro and alternatives addressing confusion with explicit specializations.
• Added Kona Evolution Working Group Incubator (EWGI) polls and acknowledgments.
• Corrected examples.

1.4 R0 (2018-10-08)

• Initial draft. [P1219R0]

2 Introduction

Homogeneous function parameter packs would replace fixed-arity overload families with one declaration for C++29. Each pack has one declared element type with ordinary parameter initialization and conversions.

template <auto... vs>
void f();

void f(auto... vs);

// Legal since C++11: T is not a parameter pack, but vs is.
template <class T, T... vs>
void foo();

// Proposed (ill-formed in C++26): vs is a pack of T parameters.
template <class T>
void foo(T... vs);

Table 1’s lower-right declaration is ill-formed because T names one type, leaving T... vs no pack to expand. [temp.variadic]/8 [dcl.fct]/25 Under our proposal, vs would be a pack of T parameters.

A fixed or explicitly supplied T permits ordinary conversions from different source types. Deduced T requires consistent deductions across applicable arguments. [temp.deduct.type]/2 Unlike homogeneous template packs’ constant arguments, function arguments may be runtime values. Their count remains compile-time. [temp.variadic]/9

An invented constant template parameter carries that count, making the declaration an abbreviated function template whose specializations have ordinary fixed-arity function types.

As in R2, one trailing homogeneous pack covers the library use cases and lets the remaining arguments determine its length. Declaration-site lengths need new syntax and multiple packs need argument-partitioning rules so both remain deferred. Existing pack expansions retain their meanings.

Earlier revisions received EWGI support, but Belfast’s 2019 EWG poll to accept P1219 for C++23 failed. [P1219-EWG-RECORD] We return with library comparisons, further evidence of programmer demand, and a revised count model.

Both named int... values and unnamed int... packs are proposed. Since Belfast, C++26 has deprecated the comma-less C-varargs spelling. [depr.ellipsis.comma] We pair mandatory commas and reclamation in C++29 so parameter names do not change pack meaning. We ask EWG to confirm that direction first.

3 Library use cases

3.1 Combine call-site diagnostics with count-dependent results

Abseil’s internal Layout<Ts...> describes one array per template argument in one allocation. PartialType<N> records how many leading sizes Partial receives, even when their values are runtime. [ABSL-LAYOUT]

With runtime size_t values int_count and double_count:

using ArrayLayout =
    absl::container_internal::Layout<int, double, char>;

auto ints_known = ArrayLayout::Partial(int_count);
auto ints_and_doubles_known =
    ArrayLayout::Partial(int_count, double_count);

The calls return ArrayLayout::PartialType<1> and ArrayLayout::PartialType<2>. One supplied size permits int and double offsets and two also permit char:

auto double_offset = ints_known.Offset<double>();
auto char_offset = ints_and_doubles_known.Offset<char>();

ints_known.Offset<char>() is rejected at compile time because the preceding double size is missing. A replacement must preserve these count-selected result types and offsets. [ABSL-LAYOUT]

The shipped declaration deduces every argument type and casts to size_t in its body. A homogeneous pack would deduce only the count and initialize size_t parameters at the call:

template <class... Sizes>
static constexpr PartialType<sizeof...(Sizes)>
Partial(Sizes&&... sizes) {
  static_assert(sizeof...(Sizes) +
      StaticSizeSeq::size() <= sizeof...(Ts));
  return PartialType<sizeof...(Sizes)>(
      static_cast<size_t>(
          std::forward<Sizes>(sizes))...);
}

static constexpr auto
Partial(size_t... sizes)
    -> PartialType<sizeof...(sizes)> {
  static_assert(sizeof...(sizes) +
      StaticSizeSeq::size() <= sizeof...(Ts));
  return PartialType<sizeof...(sizes)>(
      sizes...);
}

A trailing return type puts sizes in scope for sizeof...(sizes). [basic.scope.param]/1

For int signed_count, Abseil’s authors want warnings for ArrayLayout::Partial(signed_count) but not ArrayLayout::Partial(3). Their comment explains that explicit casts suppress both, while implicit forwarding-body conversions can warn for both. It calls for “a variable number of parameters of a certain type, a.k.a. homogeneous function parameter packs”.

Fixed size_t parameters expose the original argument expressions to call-site conversion diagnostics. [expr.call]/7 Ordinary initialization also rejects explicit-only conversions, such as explicit operator size_t(), accepted by the shipped static_cast. [over.match.conv]/1 [expr.static.cast]/5 A std::convertible_to<size_t> constraint leaves conversions in the body. [concept.convertible]/1

Warnings depend on the compiler and enabled options. Converting negative integers to unsigned remains well-formed. [conv.integral]/3

For Layout<Ts...> without static sizes, current C++ can preserve conversions and result types with overloads for arities zero through sizeof...(Ts). Its constructor already expands an index pack through IntToSize for size_t parameters. Here LayoutType<N, Ts...> stands for PartialType<N>:

template <size_t>
using IntToSize = size_t;

template <class Seq, class... Ts>
struct PartialOverload;

template <size_t... Is, class... Ts>
struct PartialOverload<std::index_sequence<Is...>, Ts...> {
  static constexpr LayoutType<sizeof...(Is), Ts...>
  Partial(IntToSize<Is>... sizes) {
    return LayoutType<sizeof...(Is), Ts...>(sizes...);
  }
};

template <class Seq, class... Ts>
struct PartialOverloads;

template <size_t... Ns, class... Ts>
struct PartialOverloads<std::index_sequence<Ns...>, Ts...>
    : PartialOverload<std::make_index_sequence<Ns>, Ts...>... {
  using PartialOverload<std::make_index_sequence<Ns>, Ts...>::Partial...;
};

Layout exposes these generated overloads by inheriting PartialOverloads<std::make_index_sequence<sizeof...(Ts) + 1>, Ts...>. A homogeneous pack needs only one declaration.

3.2 Preserve conversion ranking without fixed-arity wrappers

CasADi’s horzcat, vertcat, and diagcat concatenate symbolic matrices horizontally, vertically, and diagonally. At d30fbc4, fifteen positional wrappers cover arities two through six. The enclosing SparsityInterface specialization fixes their const MatType& parameters. [CASADI-CONCAT] The library call vertcat(dx_cat, 1) relies on scalar conversion to that type.

inline friend MatType vertcat(
    const MatType& x, const MatType& y) {
  return vertcat(std::vector<MatType>{x, y});
}

inline friend MatType vertcat(
    const MatType& x, const MatType& y,
    const MatType& z) {
  return vertcat(std::vector<MatType>{x, y, z});
}

friend MatType vertcat(
    const MatType& first,
    const MatType& second,
    const MatType&... rest) {
  return MatType::vertcat(
      std::vector<MatType>{first, second, rest...});
}

The fixed parameters retain the two-operand minimum and the trailing pack removes the six-argument ceiling, likewise for horizontal and diagonal concatenation.

A constrained deduced pack in the same class also replaces the overload family:

template <class... Args>
  requires (sizeof...(Args) >= 2 &&
            (std::is_convertible_v<
                const Args&, const MatType&> && ...))
friend MatType vertcat(const Args&... args) {
  return MatType::vertcat(std::vector<MatType>{args...});
}

The declarations differ when an argument converts to multiple matrix types. For mutable SX symbolic and IM indices (symbolic-expression and integer matrices), indexing yields SubIndex<SX, IM> derived from SX. [CASADI-PROXY] Consider these constructed calls:

vertcat(symbolic(indices), 1);
vertcat(1, symbolic(indices));

Argument-dependent lookup finds concatenation functions for SX and the proxy’s IM template argument. [basic.lookup.argdep]/3-4 Fixed parameters select SX in both calls because base binding outranks conversion to IM. [over.ics.rank]/2.1 With deduced packs, both candidates bind directly and satisfy the constraints, making both calls ambiguous. [over.match.best.general]/2 Homogeneous packs retain the fixed destinations for ranking.

Fixing only the first parameter as const MatType& leaves the second call ambiguous. Even two fixed parameters leave vertcat(1, 1, symbolic(indices)) ambiguous because its distinguishing operand is in the deduced tail.

Competing std::initializer_list<SX> and std::initializer_list<IM> overloads are also ambiguous: list ranking uses the worst element conversion so the scalar’s user-defined conversions erase the indexed operand’s distinction. [over.ics.list]/5

Current C++ supports arbitrary counts with an explicit destination, as in SX::vertcat({symbolic(indices), 1}). Existing or generated wrappers preserve positional calls. A homogeneous pack would directly express two or more const MatType& parameters with one declaration per operation.

3.3 Broader demand for fixed-type packs

R2 includes deduced-type and fixed-type homogeneous interfaces. [P1219R2] Later requests seek fixed-type positional interfaces [REDDIT-ENUM-PACK] [SO-STRING-VIEW-CONCAT], addressing body conversions [SO-TYPED-ACCUMULATOR], ordinary conversion ranking [LOEW-HOMOGENEOUS-OVERLOADS], and by-value initialization without additional body construction. [MAZIERES-PARAM-PACK] The count would also permit constraints such as even arity. [SO-10]

The discussions offer constrained packs and fixed-parameter emulations. For these interfaces, we consider direct parameter typing easier to write, maintain, and reason about than constraints, helpers, or generated overloads. It reduces helper code and repeated declarations while retaining ordinary initialization and conversion ranking.

4 Sequence alternatives

Initializer lists and vectors accept fixed-type elements as one sequence argument, without a parameter per element.

Neither an initializer list nor a vector carries its count in its type, preventing count-selected return types. Static spans, arrays, and array references do carry it, permitting results such as Abseil’s PartialType<N> even with runtime elements. For example:

template <std::size_t N>
auto span_count(std::span<const std::size_t, N>) {
    return std::integral_constant<std::size_t, N>{};
}

template <std::size_t N>
auto array_count(const std::size_t (&)[N]) {
    return std::integral_constant<std::size_t, N>{};
}

const std::size_t sizes[]{3, 5};
auto from_span = span_count(std::span{sizes});
auto from_array = array_count(sizes);
auto from_braces = array_count({3, 5});

All three results are std::integral_constant<std::size_t, 2>. Since array_count({3, 5}) deduces a bound and initializes a temporary array, an analogous array-reference Partial({int_count, double_count}) could return PartialType<2> without named storage or an explicit extent. [temp.deduct.call]/1

Braced arrays use list-initialization, rejecting narrowing accepted by ordinary size_t parameters in Abseil’s signed-variable case. Empty braces cannot deduce the bound in array_count({}). [temp.deduct.call]/1 Explicit zero also fails because built-in array bounds must be positive. [dcl.array]/1 Static spans and std::array permit zero extent but retain grouped arguments. [span.cons]/1 A homogeneous size_t pack permits both the conversion and zero arguments positionally.

A span over an existing array avoids constructing another array but requires matching element types apart from permitted qualification conversions. Thus an int array cannot initialize std::span<const std::size_t>, although size_t parameters could accept its individual elements. [span.cons]/13

Callers can convert elements by constructing an explicitly typed std::array<T, N> or vector from braces. A const-element span also accepts a temporary array through double braces such as {{1, 2}}. The temporary array lasts through the call’s full-expression. [class.temporary]/6.10 Both approaches retain list-initialization restrictions.

A container’s element type fixes the conversion destination before the call. Homogeneous packs would preserve CasADi’s selection by per-argument conversion ranking, without requiring callers to choose a matrix type or group arguments.

A constrained std::ranges::input_range suits sequence input, especially runtime-sized or non-contiguous sequences. The concept supplies no compile-time count, though deduction may retain one from an array or static-span type. Convertibility constraints neither perform conversions nor provide separate parameters for the original arguments so they do not reproduce Abseil’s call-site diagnostics.

5 Design decisions

5.1 Definitions

Each homogeneous function parameter pack (homogeneous pack) gets an invented constant template parameter for its length.

Its parameter pattern is the declaration without the declarator ellipsis. [temp.variadic]/6.1 After placeholder processing invents a type parameter pack for auto... [dcl.fct]/22, classification occurs before enclosing-template substitution: a pattern with no unexpanded pack is homogeneous. Ordinary expansions remain expansions even when all resulting types coincide.

An occurrence is unexpanded unless inside a nested expansion’s pattern. Indexing consumes the indexed pack name, leaving unexpanded packs in the index for an enclosing expansion. Neither decltype nor ordinary sizeof consumes packs. This follows existing expansion boundaries [temp.variadic]/6-8 and constraint rules [temp.constr.fold].

In the following table, xs can denote a constant template parameter pack, function parameter pack, init-capture pack, or structured binding pack.

Each homogeneous case has its own count. Even at zero, substitution requires valid types, indices, folds, and array bounds. The last row’s nested requirement determines the bool requires-expression’s value without constraining the function.

5.2 Pack declarations

The same declarator syntax covers ordinary expansions and homogeneous packs, whose patterns need not mention template parameters:

// heterogeneous function parameter pack
template <class... T>
void f(T... v);

// homogeneous function parameter pack
template <class T>
void f(T... v);

// homogeneous function parameter pack
void f(int... v);

Since C++20, function templates needing no template parameter names can use abbreviated syntax with parameter placeholders such as auto. [P1141R2] [dcl.fct]/22 Likewise, a homogeneous pack makes its declaration an abbreviated function template before body parsing, omitting the template-head when no template parameters are explicit.

Its invented, unnamed constant template parameter replaces R2’s hidden, deduction-only length component of specialization identity. [P1219R2] Ordinary template arguments permit explicit counts, target-free specialization selection for address-taking or callable-deducing interfaces, and ordinary template-argument identity.

The count has type std::size_t, as does sizeof.... The wording uses the type of sizeof to avoid requiring a declaration or header. [expr.sizeof]/5

A specialization’s count is visible in std::meta::template_arguments_of. [meta.reflection.queries]/59 For named packs, sizeof...(values) exposes it within the parameter’s scope.

As function templates, these declarations cannot be virtual, block-scope, or members of local non-closure classes. [temp.mem]/2-4 [dcl.fct]/24 Definitions must meet template reachability requirements, except for explicitly instantiated specializations. [temp.pre]/10 Replacing non-template overloads requires checking these restrictions, ABI compatibility, and overload ordering.

[P1061R10] section 3.3 removed non-template structured binding packs after objections to R9’s implicit template region. That region covered an ordinary function’s remainder after the binding declaration. Here, the signature declares the whole function a template.

A homogeneous pack must be the only function parameter pack, appear last, and have no following C ellipsis. Preceding non-pack parameters leave the remaining arguments to determine its count without partitioning. Its parameters otherwise behave like any function parameter pack’s.

These declarations violate the placement rules:

void misplaced(int... values, int last);
void two_packs(int... left, double... right);
void trailing_varargs(int... values, ...);

The pack must declare the function’s or lambda call operator’s own parameters. Thus using Callback = void(int... values); and void register_callback(void (*callback)(int... values)); remain ill-formed: neither declares a function template to own the count. These forms need separate count-introduction and deduction rules. Ordinary expansions in aliases and nested function types stay unchanged. The exception is a captureless generic lambda’s conversion template, which shares the call operator’s count.

void named_f(int... values);
auto* named_pf = &named_f<3>;

template <class T>
void named_g(T... values);
auto* named_pg = &named_g<int, 3>;

Both pointers have type void (*)(int, int, int). The homogeneous declarations may omit parameter names.

The count follows all explicit template parameters and invented auto type parameters without changing their positions:

template <class Tag>
void tagged(auto tag, int... values);
auto* tagged_pair = &tagged<void, char, 2>;

The arguments supply Tag, the invented tag type, then count, giving void (*)(char, int, int). Lambda call operators use the same order.

The trailing-pack rule keeps invented parameters in function-parameter order. Non-trailing support would require revisiting this.

5.2.1 Alternatives

We retain R2’s rejection of a bare template introducer and empty template heads. [P1219R2] Empty template <> introduces an explicit specialization and cannot introduce a homogeneous pack. [temp.expl.spec]/1 The candidate wording states this explicitly, because the working draft lacks the corresponding auto rule.

In int auto... values, auto has no type to deduce and would only mark template status. int is not a concept constraint either. We reject this redundant marker and retain symmetry with homogeneous template packs such as std::size_t... values.

R2 considered a template <...> marker for homogeneous packs [P1219R2], permitting unnamed packs without reclaiming comma-less C varargs. The lambda spelling would be []<...>(int... values) {}.

Kona’s discussion objected to another template introducer without a template-head. [P1219-EWG-RECORD] The abbreviated-template model adds no token: an ellipsis before the name already declares packs in Ts... values and auto... values. The invented count supplies the template parameter as auto’s invented type parameter does. R2 reports that Richard Smith suggested the marker, which he and David Vandevoorde thought simpler to implement across compilers. Smith later agreed by e-mail that implementations supporting P1141R2’s headless declarations should handle homogeneous packs without added syntax. [P1219R2] We prefer the existing cue.

The invented count covers the present use cases, though declaration-site lengths would let authors name and position it. We defer these lengths and multiple or non-trailing homogeneous packs, which need count association and deduction rules. Poll 4 (Proposed EWG polls) asks EWG to confirm this scope. [P2347R2] proposes deducing a single non-trailing pack’s length from argument count and required trailing parameters.

R2’s bracketed length spelling conflicts with C++26 pack indexing: Ts...[Len] already selects one type. [P1219R2] [dcl.type.pack.index] A marker cannot resolve this conflict, but other spellings remain possible. Restoring abstract array-pack grammar remains separate.

5.2.2 Type deduction

In these proposed functions, sum fixes the element type to int while total uses the ordinary template parameter T:

int sum(int... values) {
    return (0 + ... + values);
}

template <class T>
T total(T... values) {
    return (T{} + ... + values);
}

total requires consistent T deductions from all applicable arguments, not the first argument’s type or a common type. [temp.deduct.type]/2 Fixed types in sum or total<int> allow ordinary conversions. Explicit T leaves count deduction unchanged, while sum<2>(1, 2.5) and total<int, 2>(1, 2.5) fix the count.

Specialization identity comes from the template and its arguments, including the count converted to its parameter type. With a fixed element type, source argument types do not affect identity: sum(1, 2), sum(1.0, 2.0), and sum<2>(1, 2) all select sum<2>.

The template-argument component of [defns.signature.spec] and [defns.signature.member.spec] covers the invented count without a signature change or separate pack-length component.

Different template arguments can produce identical adjusted function types, which alone do not identify specializations. [temp.deduct.general]/3-4

An explicit count must equal the remaining argument count: sum<3>(1, 2, 3) and sum<0>() are valid, but sum<3>(1, 2), sum<2>(1, 2, 3), and sum<0>(1) are rejected. Ordinary constant template argument rules apply to the invented unsigned type. sum<>() deduces zero.

At zero count, the element type must be explicit, deduced elsewhere, or defaulted. Its pattern still undergoes substitution.

Ordinary reference binding and parameter adjustment apply, as do list-initialization and narrowing checks for braces. Temporaries bound to reference parameters last through the call’s full-expression. [class.temporary]/6.10 Packs change neither that lifetime nor argument-initialization evaluation order. [expr.call]/7-8

5.2.3 Target types for initialization

A fixed parameter type supplies a target for braced initializers and overloaded function names in these proposed declarations:

struct Point {
    int x;
    int y;
};

void plot(const Point&... points);

using Step = void (*)();
void start();
template <class T> void start(T mode);
void stop();

void run_all(Step... steps);

auto... cannot deduce from bare braces or the start overload set containing a function template. [temp.deduct.type]/5.8-5.9 Current C++ supplies targets through std::initializer_list<Point> and std::initializer_list<Step>, with calls plot({{0, 0}, {4, 5}}) and run_all({start, stop}). Deduced packs instead accept explicit Point objects and static_cast<Step>(start). [over.over]/1-3

5.2.4 Address-taking

When taking sum or total addresses, the target function type supplies the count. A length-two sum specialization has type int(int, int).

Corresponding homogeneous packs require corresponding parameter patterns and invented count parameters in the same template position. Parameter names do not distinguish declarations. Matching specialization function types alone do not make ordinary expansions correspond to homogeneous packs.

The bare name sum supplies no target type to callable-deducing interfaces, preventing deduction in std::thread(sum, 1, 2), std::invoke(sum, 1, 2), and std::function<int(int, int)> callback = sum. [temp.deduct.type]/5.8.3 Each can use sum<2>, a pointer initialized with a matching target type, or a forwarding lambda. Likewise, only decltype(sum<2>), not decltype(sum), identifies a specialization.

Existing explicit-specialization and explicit-instantiation syntax remains. Here, omitted counts are deduced from ordinary parameter lists:

template <>
int sum<>(int value) {
    return value + 10;
}

template int sum<>(int, int);

Explicit template <> int sum<1>(int value) and template int sum<2>(int, int) identify the same specialization and instantiation. The counts must match their parameter lists.

5.2.5 Overload ordering

Ordinary conversion ranking, partial ordering, constraint subsumption, and element-type comparisons remain. Unordered candidates stay ambiguous, without preference for homogeneous syntax. Partial ordering compares declarations, preserving pack origins [temp.deduct.partial]/8, rather than only resulting fixed-arity specializations. [temp.func.order]/3-6

Calls without pack arguments contribute no element-type comparisons. Default template arguments can establish viability without fixing dependent patterns for ordering.

For packed(1, 2) in Table 9, deduction between transformed pack patterns succeeds both ways. Both declarations have trailing packs so [temp.deduct.partial]/11 prefers neither. Adding the deduced homogeneous overload to the heterogeneous catch-all therefore makes same-type calls ambiguous. A fixed element type can still establish ordering. The candidate wording adds no preference. We would accept a tie-break preferring a homogeneous trailing pack over an ordinary one for equal-length calls, allowing this addition to existing Ts... overload sets, and ask EWG to decide in Poll 8 (Proposed EWG polls).

Replacing constrained emulation can also change overload selection. Beside template <class T> void single(T), void single(std::same_as<int> auto...) loses for single(1). Replacing it with void single(int...) produces Table 9’s ambiguity. [temp.deduct.partial]/8

Length-dependent associated constraints require count determination before satisfaction substitutes ordinary template arguments, including counts and enclosing specializations’ arguments, without separate count bindings. Rechecking the same atomic constraint with the same arguments retains the existing consistency requirement. [temp.constr.atomic]/3

The count adds no atomic-identity or subsumption test, including no arithmetic implication between separate sizeof...(values) >= 1 and sizeof...(values) >= 2 predicates. [temp.constr.atomic]/2 [temp.constr.order]/1.2

5.2.6 Constructors

If supported, homogeneous constructors would be implicit templates in ordinary overload selection. [over.match.best.general]/2.4 Initializer-list constructors, however, have priority under [over.match.list]/1.

struct Values {
    Values(std::initializer_list<int>);
    explicit Values(const int&, const int&);
};

struct Values {
    Values(const int&... elems);
    explicit Values(const int&, const int&);
};

5.3 Lambdas

Lambdas use the same count model. This proposed call operator remains a template despite its fixed element type:

auto product = [](double... factors) {
    return (1.0 * ... * factors);
};

Here, product() and product(0.5, 0.8) return 1.0 and 0.4. The count lets product.operator()<2>(0.5, 0.8) select the specialization with count two. A current-language std::same_as<double> auto... factors lambda accepts both ordinary calls but takes element types as template arguments.

For double (*multiply)(double, double) = product, the captureless lambda’s generic conversion function template deduces count two from the target. Unary +product lacks a target and count and is rejected. Conversion remains available only without a lambda-capture or explicit object parameter. [expr.prim.lambda.closure]/12-14

An enclosing pack’s ordinary expansion, including indexed forms, needs no independent count and alone does not make a lambda generic. [expr.prim.lambda.general]/6

Homogeneous pack elements would follow ordinary capture and lifetime rules for function parameters.

5.4 Pack indexing

Homogeneous packs would use existing expansion, folding, and constant-index access. Here, select_sample indexes with a template argument:

template <std::size_t I>
double select_sample(double... samples)
    requires (I < sizeof...(samples)) {
    return samples...[I];
}

With runtime double reading, select_sample<1>(reading, 0.5, 1.0) selects the second sample using the supplied index and deduced length. Index 3 fails the constraint. A std::same_as<double> auto... samples pack gives the same results. [expr.prim.pack.index]/2-4

In parameter patterns, Ts...[1] selects the second type. As in Definitions, Ts...[Is] consumes Ts, leaving Is for enclosing expansion. [temp.variadic]/6.15 [dcl.type.pack.index]/2-4 The index pack can differ in length from Ts and repeat types.

Rows in Table 12 are independent, with enclosing declarations of Ts and Is and valid selected indices.

With a valid selected type, unnamed Ts...[1]... denotes one parameter followed by C varargs in C++26. Indexing consumes Ts so the final ellipsis follows [dcl.fct]/26’s C-varargs branch. Reclamation changes it to a homogeneous pack. Inserting a comma, as in Ts...[1], ..., preserves C varargs.

Scalar indexing fixes the proposed pack’s type before count deduction:

template <std::size_t I, class... Ts>
auto selected_counter() {
    return [](Ts...[I]... values) {
        return sizeof...(values);
    };
}

auto count_doubles = selected_counter<1, int, double, char>();

count_doubles(0.5, 1.0) returns 2: scalar indexing selects double from three types before the call independently deduces its count.

An empty outer Is expansion need not instantiate indexed selection. [temp.variadic]/9 A fixed index must still designate an element whenever its type is required, including homogeneous lambda declarations with zero-argument calls. [dcl.type.pack.index]/2

5.4.1 Array parameters

In C++26, int... values[Is] expands Is into array bounds, leaving none for enclosing folding. Positive extents 1, 2, and 3 adjust to three int* parameters. Zero extents are independently invalid. [dcl.array]/1

C++26 [dcl.name]/1 has no array-suffix production for abstract (unnamed) pack declarators. P2662R3 removed it with pack indexing. [P2662R3]

The proposal retains this grammar. An array alias could supply an unnamed homogeneous parameter type with ordinary adjustment and an extent independent of its count. Parenthesized unnamed pack declarators (CWG1488) remain out of scope because aliases need no new declarator form.

6 Reclaiming the deprecated comma-less spelling

The C++29 design requires a comma between a parameter list and C varargs and reclaims the comma-less spelling for unnamed homogeneous packs. Otherwise, void f(int... args) would declare a homogeneous pack while void f(int...) retained deprecated C varargs so adding or removing a name would change meaning and template status. The polls assume this pairing. Reclamation also permits omitting unused names as void g(auto...) and template <class... Ts> void h(Ts...) already do. [depr.ellipsis.comma]

James Touton’s [P0281R0] proposed removing comma elision in 2016 but failed because of its impact on existing code ([P3176R1], section 2). Kona’s 2019 EWGI vote favored mandatory commas by 10/6/1/0/0 without establishing a C++29 reclamation timetable. [P1219-EWG-RECORD] Jan Schultke’s [P3176R1], The Oxford variadic comma, chose deprecation: no proposed feature required removal, the earlier attempt had failed, and the motivation did not justify abruptly breaking code (section 6.1). This proposal requires removal.

One standard cycle separates C++26 deprecation from proposed C++29 reclamation. Adding a comma preserves C varargs in every language mode, permitting migration before C++29. GCC enables -Wdeprecated-variadic-comma-omission by default in C++26 mode. [GCC-CXX-DIALECT] Clang enables -Wdeprecated-missing-comma-variadic-parameter by default and reports P3176R1 implemented. [CLANG-DIAGNOSTICS] [CLANG-20-NOTES] R2’s ACTCD19 header survey found 6,318 comma-less C-varargs lines: 6,182 in Boost copies (879 after deduplication) and 136 elsewhere. [P1219R2] This predates deprecation and does not measure remaining migration cost in maintained and vendored code.

A one-cycle precedent is [P1161R3]’s C++20 deprecation of unparenthesized comma subscripts and [P2128R6]’s C++23 replacement. P2128R6 deliberately withheld multidimensional meaning from C arrays and existing valarray interfaces, making deprecated expressions ill-formed before any later reinterpretation. It cannot establish that immediate reinterpretation of comma-less varargs is harmless.

A deprecated subscript could acquire new meaning silently inside any expression. For comma-less declarations, the diagnostics above can locate the comma insertion preserving meaning in every language mode. Unmigrated declarations can still change meaning without required diagnostics, as below.

6.1 Current rules

A varargs ellipsis denotes C varargs, not a parameter pack. C23 and C++26 permit ... without preceding parameters. [N3096] C++26 also permits but deprecates omitting the comma between a parameter list and C varargs. [depr.ellipsis.comma]

A final ellipsis that could belong to an abstract (unnamed) declarator declares a pack if its type names an unexpanded template parameter pack or contains auto, otherwise C varargs. [dcl.fct]/26 Writing basic_string_view<Char, Traits> svs ... to declare a pack gives C varargs today. [SO-STRING-VIEW-CONCAT]

These C++26 declarations therefore differ:

// declares a variadic function template with a function parameter pack
template <class... T>
void f(T...);

// same as void f(T, ...)
template <class T>
void f(T...);

6.2 Proposed change

Requiring the comma and removing unnamed disambiguation lets comma-less declarations introduce homogeneous packs. Standalone ..., comma-separated C varargs, and ordinary pack expansions retain their meanings.

Table 13’s first and last rows become ill-formed, requiring diagnostics. The middle rows stay valid at namespace scope without required diagnostics for changed meanings. Reclaimed void f(int...) becomes ill-formed at block scope, as a virtual member, or in a local non-closure class under existing template restrictions. [dcl.fct]/24 [temp.mem]/2-3 The third row already has these restrictions.

The six-dot declaration template<class... Ts> struct S { static void f(Ts......); }; is valid today: S<int>::f(1, 2.0) passes its second argument through C varargs. Migration must insert a comma between the ellipses, including in named expansions: Ts... values... becomes Ts... values, .... Removing the last ellipsis would change the interface. [P3176R1]

An old f(1, 2.5) call to void f(int...) passed a double through C varargs. Reclamation instead initializes two int parameters, using an ordinary floating-integral conversion. It also permits empty calls and produces fixed-count specializations without C ellipsis. Even successful recompilation thus leaves a source and potential link compatibility break. Adoption includes approving these known source and link incompatibilities under [SD10], which Poll 2 (Proposed EWG polls) asks separately.

6.2.1 Migrating definitions and function types

Legacy definitions using va_start require comma insertion to preserve the C ellipsis that homogeneous parameters cannot supply. C++26 discards the second and subsequent macro arguments so a surviving parameter name cannot portably trigger diagnostics. [cstdarg.syn]

Inconsistently migrated declarations and definitions can validly declare separate homogeneous-template and C-varargs overloads. For void f(int...) and void f(int, ...) after reclamation, zero arguments select the template. One argument convertible to int selects the non-template C-varargs overload. [over.match.best.general]/2.4 With two or more arguments all convertible to int, the template wins because ordinary conversions outrank ellipsis conversions. [over.ics.rank]/2.1 If an additional argument cannot initialize int, C varargs can remain viable. A missing selected-template definition can surface during instantiation or linking. Changing a declaration provides no link compatibility with an existing C-varargs definition.

The alias using F = void(int...) becomes ill-formed: function type aliases cannot introduce homogeneous function templates. It must become using F = void(int, ...) to retain C varargs. Reclaimed declarations no longer match C-varargs pointer targets, though fixed-arity targets can deduce a specialization’s count. Passing a formerly non-template name to callable-deducing interfaces also needs a selected specialization, typed pointer, or wrapper.

The conversion changes can also affect well-formed metaprogramming probing callability, taking addresses, or recognizing C-varargs function types. Preserving C varargs requires commas across declarations, definitions, pointer and member-pointer types, traits, and macro-generated declarations. Ordinary expansions such as template<class... Ts> void f(Ts...) stay unchanged.

Reclamation needs grammar coordination with [P3776R1], More trailing commas, including between ordinary packs and C varargs. That paper proposes trailing parameter-list commas except after C ellipsis parameters.

7 Straw polls

7.1 Proposed EWG polls

We ask EWG to take the first poll before the others. The remaining polls assume it, since the design gives a pack the same meaning with and without a parameter name (Reclaiming the deprecated comma-less spelling).

1. We want C++29 to require a comma before C varargs and to reclaim the comma-less spelling for unnamed homogeneous function parameter packs.
2. We accept the source and link incompatibilities for comma-less C-varargs declarations that Poll 1 causes, as recorded in the Annex C entry.
3. We want homogeneous function parameter packs for C++29.
4. We want C++29 to permit at most one homogeneous function parameter pack per parameter list, in trailing position, deferring declaration-site lengths and multiple or non-trailing homogeneous packs.
5. We want each homogeneous function parameter pack to have an invented constant template parameter whose argument specifies the pack’s length and participates in function template specialization identity.
6. We want functions with homogeneous function parameter packs to be function templates without requiring a template-head.
7. We want C++29 to support homogeneous function parameter packs in constructors.
8. We want a tie-break preferring a trailing homogeneous function parameter pack over an ordinary trailing function parameter pack when partial ordering would otherwise leave a call ambiguous.

7.2 Historical results

The polls in Tables 14 to 16 concern earlier revisions, before the C++26 changes addressed here. Proposed Polls 1, 3, and 6 revisit the first, second, and last rows of Table 14. The template <> row is the empty template-head spelling this revision rejects (Alternatives).

The Belfast poll (Table 16) failed. Although Kona’s public record identifies objections to template-introducing syntax and to conflicts with existing syntax, it does not establish why Belfast later failed. [P1219-EWG-RECORD]

8 Implementation experience

P1219R2 links an experimental Clang branch. [P1219R2] Its tests cover headless function and lambda declarations and the earlier template <> primary-template syntax, but do not establish implementation of this revision’s invented count model. [P1219-CLANG-TESTS] Such an implementation may not be ready for Brazil. We seek EWG design direction.

9 Wording

Wording is relative to [N5054].

9.1 Lambdas

9.1.1 General [expr.prim.lambda.general]

Modify the first sentence of [expr.prim.lambda.general]/6 and append to Example 4:

  auto x = [](int i, auto a) { return i; };               // OK, a generic lambda
  auto y = [](this auto self, int i) { return i; };       // OK, a generic lambda
  auto z = []<class T>(int i) { return i; };              // OK, a generic lambda
+ auto w = [](int... i) { return (0 + ... + i); };        // OK, a generic lambda

9.1.2 Closure types [expr.prim.lambda.closure]

In [expr.prim.lambda.closure]/5, insert after the first sentence, and in /12, insert after the second sentence:

9.2 Functions [dcl.fct]

Modify [dcl.fct]/22, /23, and /25 as follows:

9.3 Removal and reclamation

Remove the comma-less alternative in [dcl.fct]/1, the indicated wording in /3, paragraph /26, and its disambiguation footnote:

  parameter-declaration-clause:
      ...
      parameter-declaration-listopt
      parameter-declaration-list , ...
-     parameter-declaration-list ...

Remove [depr.ellipsis.comma]:

void f(int...);       // deprecated
void g(auto...);      // OK, declares a function parameter pack
void h(auto......);   // deprecated

A terminal abstract-declarator ellipsis then belongs to the parameter declaration under homogeneous-pack or existing ordinary expansion rules.

9.4 Address of an overload set [over.over]

Insert after [over.over]/3:

9.5 Variadic templates [temp.variadic]

Modify Example 2 in [temp.variadic]/2. Modify the second sentence of /5 and insert immediately after it, replace /6.1, modify /8 and /9.2, and replace the example in /15 as follows:

Retain the remaining requirements of paragraph 8, the other expansion patterns in paragraph 6, and the other element interpretations in paragraph 9.

  template<class ... Types> void f(Types ... args);
+ void g(int ... args);           // args is a homogeneous function parameter pack
  
  f();                            // args contains no arguments
  f(1);                           // args contains one argument: int
  f(2, 1.0);                      // args contains two arguments: int and double
+ g();                            // pack count is zero
+ g(2, 1.0);                      // pack count is two and 1.0 converts to int
+ g<1>(2, 1.0);                   // error: explicit pack count does not match two arguments

- template<typename ...Args>
- bool all(Args ...args) { return (... && args); }
+ bool all(bool ...args) { return (... && args); }
  
  bool b = all(true, true, true, false);

9.6 Dependency

A homogeneous-pack function type depends on its invented count until determined, even with a non-dependent element type. Existing rules make function types containing function parameter packs dependent and sizeof... value-dependent. [temp.dep.type]/10.7 [temp.dep.constexpr]/4 Count substitution follows ordinary template rules. Declaring the pack does not make unrelated expressions dependent.

9.7 Deduction

9.7.1 General [temp.deduct.general]

In [temp.deduct.general]/1, insert before Example 1, append to Example 1, and add a new example immediately after it as follows:

void f(Array<dcomplex>& cv, Array<int>& ci) {
  sort(cv);                     // calls sort(Array<dcomplex>&)
  sort(ci);                     // calls sort(Array<int>&)
}

  void g(double d) {
    int i = convert<int>(d);      // calls convert<int,double>(double)
    int c = convert<char>(d);     // calls convert<char,double>(double)
  }
+ 
+ int sum(int... n) {
+   return (0 + ... + n);
+ }
+ 
+ void h(int x, int y, int z) {
+   int i = sum(x, y, z);         // selects sum<3>
+ }

template <class T>
void f(T... v);

// error: homogeneous pack count is undetermined
auto p = &f<int>;

// OK, q has type void (*)(int, int, int)
auto q = &f<int, 3>;

9.7.2 Deducing template arguments from a function call [temp.deduct.call]

In [temp.deduct.call]/1, make the inline change and insert before Example 2:

Retain the existing [temp.deduct.call] example unchanged.

9.7.3 Deducing template arguments from a type [temp.deduct.type]

In [temp.deduct.type]/10, make the inline change and insert immediately after the sentence shown below:

9.7.4 Partial ordering of function templates [temp.func.order]

For the rules in Overload ordering, insert after [temp.func.order]/3:

9.7.5 Deducing template arguments during partial ordering [temp.deduct.partial]

In [temp.deduct.partial]/8, make the inline change and insert immediately after the sentence shown below:

Existing tie-breaks apply without a new preference for homogeneous packs, pending Poll 8 (Proposed EWG polls).

9.8 Declarations

9.9 Feature-test macro [cpp.predefined]

Add a homogeneous function parameter pack feature-test macro to Table 22, Feature-test macros. Options include __cpp_homo_fn_packs and __cpp_homogeneous_function_packs. SG10 will choose the spelling. Its value remains undetermined.

9.10 Annex C (informative) Compatibility [diff.cpp26]

Add a new entry to [diff.cpp26.dcl], before the [dcl.init] entry:

10 Conclusion

Further design and wording work depends on EWG direction. We ask EWG to confirm mandatory C-varargs commas and reclamation for unnamed packs and, on that basis, support homogeneous function parameter packs for C++29.

11 Acknowledgments

Thanks to Richard Smith, David Vandevoorde, John Spicer, and Matthias Wippich for impromptu feedback and to Zhihao Yuan for identifying an issue with an earlier make_array example.

12 References