# Pitching The Start of Variadic Generics

**URL:** <https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467>\
**Category:** Pitches\
**Tags:** generics\
**Created:** [August 24, 2021, 8:48pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467 "2021-08-24T20:48:12Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![nonsensery](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nonsensery/32/4317_2.png) [@nonsensery](https://forums.swift.org/u/nonsensery)\
**Post date:** [August 26, 2021, 4:37pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/41 "2021-08-26T16:37:14Z")

</div>

Regarding the Arity Constraints, but maybe a different direction from some of the existing discussions:

I wonder if some lightweight algebra/subscript-like syntax might be useful, like:

- Every element in `T...` must be a `Set` of the corresponding element in `U...`. This also implies that both have the same number of elements:

```swift
func allPresent<T..., U...>(haystacks: T..., needles: U...) -> Bool
  where
    T[i] == Set<U[i]>

```

- Or, for the "homogenous tuple" example above, every `T` must be the same type:

```swift
struct HomogeneousTuple<T...> where T[i] == T[j] { … }
// or maybe:
struct HomogeneousTuple<T...> where T[i] == T[i+1] { … }

```

- Specific arity: `T...` must contain at least 2 types:

```swift
func process<T...>(_ values: T...) where T[1]: Any { … }

```

In these examples:

- `1` is a concrete index
- `i` represents "any given index"
- `j` represents "the index after `i`, if there is one"
- `i+1` also represents "the index after `i` , if there is one", but allows for more complex relationships.

For the call site to be valid, the expression must be true for all indices in the type sequence(s).

_Edit: Fixed the mistake that **DevAndArtist** noted below. Thanks!_

---

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [August 26, 2021, 5:31pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/42 "2021-08-26T17:31:57Z")

</div>

Your T and U are flipped in your first example description.

Should be:

```swift
Every element in `T...` must be a `Set` of the corresponding element in `U`.

```

* * *

While I also like the idea of an index, I still think we need support for Ranges. In your current example it feels like the `where` clause would become a bit weird if the index isn't introduced earlier:

```swift
<T...> where T[i], (2 ... 10).contains(i), T[5] == String

// slightly better
<T*{2,10}> where T[5] == String

```

---

<div class="post-metadata">

**Author:** ![David\_Sweeris](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_sweeris/32/31302_2.png) [@David\_Sweeris](https://forums.swift.org/u/David_Sweeris)\
**Post date:** [August 26, 2021, 7:34pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/43 "2021-08-26T19:34:28Z")

</div>

> [@codafi](#):
>
> You can find the link to the text of the pitch here [TypeSequences.md · GitHub](https://gist.github.com/CodaFi/a461aca155b16cd4d05a2635e7d7a361)

Instead of `_countTypeSequence(xs)`, what about

```swift
func measure<T...>(_ xs: T...) -> Int {
  xs.#count // "#" already vaguely means "compiler wizardry" to me
}

```

or, a bit better IMHO, since it's `T...` itself that dictates the number of elements, not any particular instance of `T...`

```swift
func measure<T...>(_ xs: T...) -> Int {
  (T...).count
}

```

WRT to the spelling of `_mapTypeSequence`, what about just using `map`, but needing to provide a name for the particular type of whichever element you're working with in `<>`?

```swift
func cut<T..., U...>(_ xs: T..., transform:(T...) -> U...) -> U... {
  xs.map<T> { //
    // Not sure if types should need the `.self` suffix here. I vote
    // no, but I don't like that rule in regular Swift anyway.
    switch T {
    case Int: return $0 * 2
    case String: return "Hello, " + $0
    case View: return $0.padding(20)
    case Equatable: return { other: T in $0 == other }
    case CustomStringConvertible: return $0.description
    // ...
    case _: return "\(T.self)"
    }
  }
}

```

> **side note**
>
> (Wow, that's a lot of "return"s in there! Sure would be nice if the compiler could infer them in instances where a `switch` is the only statement in a function or closure which is supposed to return something, and the `case` in question only has a single expression...)

Setting aside the desire to keep this spelled different from the regular `map` (which this technically does, since `map` normally has two generic parameters, not one), the `<>` part also provides a way to specify which type you're referring to if you've nested multiple maps with the same type sequence:

```swift
func convolutedExample <T..., U...> (xs: T..., ys: T...) -> U... {
  xs.map<X> { x in
    ys.map<Y> { y in
      if X == Y { return "\(X.self) == \(Y.self), how boring..." }
      // do whatever less boring stuff you want here
    }
  }
}

```

Anyway, moving on...

> [@Nobody1707](#):
>
> I think @xwu is right about the splatting operator. There's no reason we can't use a prefix `*` for it. I'm not sure about the spelling for type sequences, but I can't really think of anything better than either `T...` or `...T` off the top of my head.

What about `#`?

> [@Jumhyn](#):
>
> I also like the "zero or more" regular expression connection that the `T*` spelling admits (and could we add `T+` as a lightweight "one or more" spelling in the future...?).

We could (though perhaps not "should") use those _and_ `…` — we could use `*` or `+` to denote “zero or one (respectively) or more of this type”, and postfix `…` to denote “zero or more types”:

```swift
struct Foo <Type1: T…, Type2: (U, V…), Type3: (W…)+, Type4: (X+, Y…)*> {
  var t1: Type1 // a heterogeneous sequence of types whose length is >= 0
  var t2: Type2 // a heterogeneous sequence of types whose length is > 0
  var t3: Type3 // a homogeneous sequence whose length is > 0 of heterogeneous type sequences whose lengths are >= 0
  var t4: Type4 // a homogeneous sequence whose length is >= 0 of heterogeneous type sequences, each of which is a homogeneous type sequence whose length is > 0 followed by a heterogeneous type sequence whose length is >= 0
}

```

I must admit, it _is_ a bit cryptic if you haven't been exposed to regular expressions, but it doesn't seem too hard to explain either (says the guy who first learned about `*` and `+` in this context many years ago). I mean, at some point I think we have to accept that code written about complex subjects might have complex syntax -- we just need to avoid making the syntax _unnecessarily_ complex. That said, while this wouldn't bother me personally, I'm not the only person who uses Swift and I wouldn't be even a little bit surprised if someone comes up with a better way.

---

<div class="post-metadata">

**Author:** ![maustinstar](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/maustinstar/32/12736_2.png) [@maustinstar](https://forums.swift.org/u/maustinstar)\
**Post date:** [August 26, 2021, 7:40pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/44 "2021-08-26T19:40:41Z")

</div>

**Type sequence mapping seems unclear.** I feel mapping one type sequence to another type sequence is an important use case.

* * *

If I want to map `T…` to the generic constraint of another type, for example, mapping parameter types `(A, B, C, …, Z)` to return type `(Result<A>, Result<B>, Result<C>, …, Result<Z>)`.

Something like `func foo<T…>(bar: T…) -> Result<T…>` seems like the return type is `Result<(A, B, C, …, Z)>`.

Something like `func foo<T…>(bar: T…) -> (Result<T>)…` to me, does not clearly indicate that `T` is a variadic type in the return type.

* * *

**Type sequence mapping could possibly be defined like so:**

`func foo<T…, U…>(bar: T…) -> U… where U == Result<T>`

Note, the where clause does not use the `…` syntax, and instead acts more like a for each U, given some T. I think this is the most clear unless we add some new syntax for type sequence mapping.

* * *

Another example of mapping one variadic generic constraint to another variadic generic constraint:

`func mapResults<T…, U…, V…>(from requests: T…) -> U… where T == Request<V>, U == Result<V>`

* * *

**Edit: this seems similar to arity constraints, but maybe the proposal should more clearly define how it looks to use a type sequence as a return type.**

---

<div class="post-metadata">

**Author:** ![nonsensery](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nonsensery/32/4317_2.png) [@nonsensery](https://forums.swift.org/u/nonsensery)\
**Post date:** [August 26, 2021, 8:04pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/45 "2021-08-26T20:04:56Z")

</div>

Your post made me wonder about supporting ranges within the subscript, like:

```swift
where T[2...10]: ExpressibleByIntegerLiteral

```

I'm not sure if that would be _useful_, but I find it interesting 😄

* * *

Another thought: My explorations didn't include any enforcement of an upper bound. One way to express an upper bound might be to declare that index to be `Never`, like…

- Specific arity: `T...` must contain at least 2, and no more than 10 types:

```swift
func process<T...>(_ values: T...)
  where
    T[1]: Any,
    T[i+10] == Never

```

That's not especially graceful. And it doesn't strictly prevent the type sequence `T...` from exceeding 10 members. But it would prevent _calling_ `process()` with more than 10 values.

---

<div class="post-metadata">

**Author:** ![GreatApe](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/greatape/32/2640_2.png) [@GreatApe](https://forums.swift.org/u/GreatApe)\
**Post date:** [August 26, 2021, 8:47pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/46 "2021-08-26T20:47:07Z")

</div>

`<T...> where T[i], (2 ... 10).contains(i), T[5] == String`

Ranges are good, but here I think it should say that `i` is in the range `0..<n`, where `n` is in `(2...10)`.

---

<div class="post-metadata">

**Author:** ![AliSoftware](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alisoftware/32/2764_2.png) [@AliSoftware](https://forums.swift.org/u/AliSoftware)\
**Post date:** [August 27, 2021, 12:36am UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/47 "2021-08-27T00:36:24Z")

</div>

> [@nonsensery](#):
>
> Your post made me wonder about supporting ranges within the subscript

This seems to be similar to the idea I suggested in my reply above too: [Pitching The Start of Variadic Generics - #18 by AliSoftware](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/18)

TL;DR: My suggested syntax would be:

```swift
func debugPrint<T[]>(_ values: T[])
  where T: CustomDebugStringConvertible
{
  print(values.count)
  for v in values { /* v is Any */ }
}
func needAtLeastOne<T[1...]>(_ values: T[]) {
  ...
}
func debugPrintEquivalentSyntax1<T[0...]>(_ values: T[])
  where T: CustomDebugStringConvertible
{ ... }
func debugPrintEquivalentSyntax2<T[...]>(_ values: T[]) // '...' here is the UnboundedRange operator
  where T: CustomDebugStringConvertible
{ ... }

```

And

```swift
public struct ZipSequence<Sequences[]>: Sequence
  where Sequences: Sequence 
{
   ...
   public struct Iterator: IteratorProtocol {
      public typealias Element = Sequences[].Element // maps the 'Sequences' type sequence into a type sequence of their respective 'Element'
   }
}

```

What I like about this syntax is:

- It plays well with potential future direction of specifying arity and arity ranges
- The square brackets makes it more natural (at least to me) to see and read `T[0]`, `T[1]`, `T[n]` at being different types (and not necessarily all the same like `T...` can imply due to its ressemblance with the existing variadic parameters feature)

---

<div class="post-metadata">

**Author:** ![maustinstar](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/maustinstar/32/12736_2.png) [@maustinstar](https://forums.swift.org/u/maustinstar)\
**Post date:** [August 27, 2021, 5:07pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/48 "2021-08-27T17:07:08Z")

</div>

Is there really a value in adding ranges? It seems to make more sense defining explicitly typed parameters with trailing variadic generics. I can't think of any example where indexing variadic types is more clear than providing explicit types.

If we want a single string, do something like this: `func foo<T...>(a: String, b: T...)`. This could even cover more complex cases like: `func foo<U..., V...>(a: U...) where U == (String, V...)`.

---

<div class="post-metadata">

**Author:** ![GreatApe](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/greatape/32/2640_2.png) [@GreatApe](https://forums.swift.org/u/GreatApe)\
**Post date:** [August 27, 2021, 5:43pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/49 "2021-08-27T17:43:07Z")

</div>

I'm not quite able to follow your point, but when I was talking about ranges I was referring to the dimension. Personally I only really care about cases with a fixed dimension, which would be something like `func f<variadic T[5]>(T) { }` but you could imagine wanting something to be defined for a dimension of 3, 4 or 5 for example: `func f<variadic T[3...5]>(T) { }`.

---

<div class="post-metadata">

**Author:** ![maustinstar](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/maustinstar/32/12736_2.png) [@maustinstar](https://forums.swift.org/u/maustinstar)\
**Post date:** [August 27, 2021, 6:45pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/50 "2021-08-27T18:45:40Z")

</div>

Sorry, I think I replied to the wrong comment. I think I meant to reply to @DevAndArtist, or whoever started the discussion about defining certain type conformances at certain indices. I was assuming `T[5] == String` Is trying to bind the element at index 5 to a string, or `T[3…5] == SomeProtocol` To define conformance for a certain sub range.

I was wondering what advantages this has over creating explicitly typed parameters, or multiple variadic generic groups.

---

<div class="post-metadata">

**Author:** ![ensan-hcl](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ensan-hcl/32/15186_2.png) [@ensan-hcl](https://forums.swift.org/u/ensan-hcl)\
**Post date:** [August 30, 2021, 3:59am UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/51 "2021-08-30T03:59:26Z")

</div>

I agree with you. If specific index or indices like `T[5]` (6th type parameter) have special meaning and it should be `String`, it means you should split them into different parameters, like `<T0, T1, T2, T3, T4, Rest...>`. Constraints like `where 2 <= n` have similar problem. It would mean, certain two type parameters have special meaning. Therefore, perhaps you should use perameter-split strategy like `<First, Second, Rest...>`, `<First, Middle..., Last>` or other corresponding signature for your intention.

Nevertheless, I think some type of constraints cannot be expressed without subscript-like syntax. (using @Jumhyn's `forEach` like syntax).

> [@Variadic Generics](https://forums.swift.org/t/variadic-generics/20320/126):
>
> Just gave the latest version of the document a read. Looks great! I love the idea of this being a STATIC feature. I hope we are all on the same page how this limits expressiveness. For instance, you can't express infinte lists like (0...). Also, one can't exchange the underyling type of an element of the list (with dynamic existential types, you could). But these are small prices to pay for the optimizations that the compiler can do if this is a static feature. There's one thing I would like to…

```swift
// declare fixed-length version of chain
static func buildBlock<A, B, C, D>(_ f: (A) -> B, _ g: (B) -> C, _ h: (C) -> D) -> A -> D {
    let f0 = { (value: A) in value } // f0: (A) -> A
    let f1 = { (value: A) in f(f0(value)) } // f1: (A) -> B
    let f2 = { (value: A) in g(f1(value)) } // f2: (A) -> C
    let f3 = { (value: A) in h(f2(value)) } // f3: (A) -> D
    return f3
}

// variadic version
static func buildBlock<type(n) Input, types(n) Output>(
// ~~~~~^~~~~~  ~~~~~^~~~~~   
// specify exact number of type parameters
    _ closures: ((Input) -> Output)...
) -> (Input[0]) -> Output[n-1] where 1 <= n, forEach(i, i+1 in 0 ..< n) Input[i+1] == Output[i]
// ~~~~~~~~^~~~~~~~~
// ensure i and i+1 in valid range 

```

I tried but couldn't write this function without `<=` and subscript access. When I add `FirstInput` and `LastOutput` to remove `<=` and`(Input[0]) -> Output[n-1]`, I couldn't write the signature of `closures`. I think subscript like range access would also have such usage in some rare conditions.

By the way, it also means that further discussion is required about how to treat variadic values. The pitch describes `map` , but `reduce` like operation would be also required. `Chain` would not be able to be expressed with only `map` and `for` .

```swift
static func buildBlock<type(n) Input, types(n) Output>(
    _ closures: ((Input) -> Output)...
) -> (Input[0]) -> Output[n-1] where 1 <= n, forEach(i, i+1 in 0 ..< n) Input[i+1] == Output[i] {
    // how to chain closures here...?
}

```

(EDIT) I was replying to the wrong address. This is not a reply to @nonsensery, I'm sorry 🙇‍♂️  
This is a reply to @maustinstar.

---

<div class="post-metadata">

**Author:** ![jawbroken](https://avatars.discourse-cdn.com/v4/letter/j/cc9497/32.png) [@jawbroken](https://forums.swift.org/u/jawbroken)\
**Post date:** [August 30, 2021, 12:39pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/52 "2021-08-30T12:39:12Z")

</div>

I never thought that variadic parameters deserved the shorthand `...` syntax and variadic generics are likely to be even less used than that. Perhaps consider an attribute in front of the type parameter (e.g. `@variadic`), which might also be a useful place to specify the additional constraints being discussed here, like arity.

---

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [August 31, 2021, 3:44pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/53 "2021-08-31T15:44:57Z")

</div>

As for the potential name of a keyword. An alternative name that was floating around in past thread was `pack`.

We could also explore the possibility to unfold a pack through a `where` clause.

```swift
<pack T> where T == <_, T1, ...>, T1 == String

```

Building on the keyword idea, in the future we might improve the generics UX and potentially be able to express things like:

```swift
func foo(_: pack T) 

// similar to
func bar(_: some T)

```

---

<div class="post-metadata">

**Author:** ![toph42](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/toph42/32/7807_2.png) [@toph42](https://forums.swift.org/u/toph42)\
**Post date:** [August 31, 2021, 5:44pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/54 "2021-08-31T17:44:42Z")

</div>

> [@DevAndArtist](#):
>
> `<pack T> where T == <T0, T1, ...>, T1 == String`

I think I really like this notation. Is the `T0` and `T1` implied from the `T` or would they be arbitrary placeholders? Would `<pack T> where T == <ID, ...>, ID == Equatable` be valid?

---

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [August 31, 2021, 6:00pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/55 "2021-08-31T18:00:19Z")

</div>

I would argue that this would be valid, however it should be probably `== any/some Equatable` or `ID: Equatable`, but that me nit picking on something else.

I would probably add the following to the pitched design:

- the `T == <…>` syntax would be unfolding / unpacking the variadic `pack T`
- `T[n]` could still be valid as `<pack T> where T[5] == String` would reference the type inside the pack; it does not violate or collide with the idea of static subscripts, because `T` in that context wouldn‘t be specific type, but rather a name of the variadic pack

Hence I think this could still be valid:

```swift
func foo<pack T[n]>(_: T…) 
  where 
  T == <A, B, B, _, Int, …>, 
  A: Equatable, 
  B == String, 
  T[5] == Bool,
  n >= 6 && n <= 10

// notice that `A`, `B`, and `C` were generic types,
// while the 5th type was already explicitly set to `Int`!
// we could allow this, but it‘s debatable.
// furthermore the 4th type used a “placeholder type“ `_`

foo(true, "foo", "bar", 1, 1, false, /* … */) 

```

The subscript syntax is really nice if you need to express very complex constraints where you know or need to require specific pack size. I personally wouldn‘t scrap that idea.

* * *

TLDR;

We could introduce these things in multiple phases:

1. Introduce just `pack T`
2. Introduce the ability to unpack `where T == <…>`
3. Introduce access via pack index `pack T[n]` and sizes `where n < 10`

Each of the phases would require its own discussion and proposal, and this current thread should probably just focus on #1.

---

<div class="post-metadata">

**Author:** ![GreatApe](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/greatape/32/2640_2.png) [@GreatApe](https://forums.swift.org/u/GreatApe)\
**Post date:** [August 31, 2021, 6:31pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/56 "2021-08-31T18:31:29Z")

</div>

```swift
<pack T> where T == <_, T1, ...>, T1 == String

```

This seems a bit illogical though. On the left it seems that `T` is a placeholder for an individual type in the pack, not the pack itself, but after `where` it is treated as the totality. If we want that kind of control I think something like

```swift
<pack _, T1, ...> where T1 == String

```

would make more sense.

---

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [August 31, 2021, 6:35pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/57 "2021-08-31T18:35:56Z")

</div>

> [@GreatApe](#):
>
> `<pack _, T1, ...> where T1 == String`

I read this as “placeholder type as a pack, followed by T1 which is a string, followed by dots which mean nothing to my brain“. No offense though. If anything this should maybe be written as.

```swift
<pack <_, T1, …>> where T1 == String

```

The unpacking syntax can extract the generic types from the pack and achieve the same as the index syntax. Both do partly overlap and this is expected.

```swift
<pack T> where T == <_, R, …>, R == String
<pack T> where T[1] == String // the same as above 

```

In the above example the index syntax is shorter, but we can find the opposite example as well.

```swift
<pack T> where T == <Int, Bool, String, Double, …>
<pack T> where T[0] == Int, T[1] == Bool, T[2] == String, T[3] == Double

```

---

<div class="post-metadata">

**Author:** ![GreatApe](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/greatape/32/2640_2.png) [@GreatApe](https://forums.swift.org/u/GreatApe)\
**Post date:** [August 31, 2021, 6:46pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/58 "2021-08-31T18:46:46Z")

</div>

It was just an example, I'm not proposing my syntax. I just wanted to point out the inconsistency in what `T` means. Feel free to put brackets around the argument to `pack` in my example!

This does not suffer from the inconsistency though:

```swift
<pack T> where T[1] == String

```

And it could be amended with things like `T.count == 5`. Not sure how to indicate that all individual `T`s are equal though. Perhaps just

```swift
<pack Double>

```

I prefer `variadic` to `pack` though.

Come to think of it, why not just this?

```swift
<variadic T: Int, Bool, String, Double, …>

```

---

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [August 31, 2021, 6:52pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/59 "2021-08-31T18:52:25Z")

</div>

Again, please don‘t be offended. I‘m just pitching brainstormed syntax and do not claim it to be superior to any other options. ;) I also just provided my 2cents on how I read the syntax in your example.

`:` always meant sub-typing, inheritence or protocol conformance to me. That‘s why in generics UX threads we kept referring to same type constraint as `any Collection<.Element == String>`.

I‘ve updated my initial response with a potential fix to your syntax.

---

<div class="post-metadata">

**Author:** ![jactmp](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jactmp/32/29354_2.png) [@jactmp](https://forums.swift.org/u/jactmp)\
**Post date:** [September 1, 2021, 3:28pm UTC](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467/60 "2021-09-01T15:28:12Z")

</div>

Would `any T` instead of `T...` make any sense? Such naming follows exact meaning of such generic parameter. Just asking.

[Previous page](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467.md?page=2)

[Next page](https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467.md?page=4)