SE-0399: Tuple of value pack expansion

Hello Swift community,

The review of SE-0399: Tuple of value pack expansion begins now and runs through May 29, 2023.

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager via the forum messaging feature. When contacting the review manager directly, please put "SE-0399" in the subject line.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

Thank you,

Xiaodi Wu
Review Manager


Hello, any arity zip(). What are you doing here? +1


The proposal lists an upcoming feature flag of VariadicGenerics but the Source Compatibility section of the proposal says this is an additive change with no source compatibility impact.

Is there syntax or behavior that will be enabled by turning on the upcoming feature flag in shipping releases that include this proposal?

If not, then VariadicGenerics should probably be listed as an experimental feature flag under Implementation, similar to SE-0393 and SE-0398.

And if so, the proposal should describe what functionality / syntax is being held until Swift 6 unless enabled by the upcoming feature flag.

1 Like

Oops, VariadicGenerics is an experimental feature flag, not an upcoming feature flag. Fixed in [SE-0399] `VariadicGenerics` is not an upcoming feature flag. by hborla · Pull Request #2056 · apple/swift-evolution · GitHub. Thank you for pointing this out!


You’re welcome - thanks for making the change! Both kinds of feature flags are very useful but subtly different and can be easily confused by users.


I'm trying out the latest snapshot and it seems like the implementation still uses the original syntax from 0393's future directions (e.g. repeat print(each tuple.element) instead of repeat print(each tuple)). The proposal says the implementation is on main so I assume it hasn't made it into a snapshot yet or the .element syntax is just being used until this is accepted? (I grabbed the latest snapshot toolchain this morning).

In terms of the proposal itself, I think it's really clean! I wasn't a fan of the each tuple.element syntax mentioned in 0393; treating abstract tuples the same as value packs makes so much more sense :)

I'm looking forward to trying out variadic generics in my SwiftUI-like UI framework SwiftCrossUI once there's a fix for the compiler crash that blocked me this morning. I might try and look into fixing that if I get the time. I've already had a go at updating the SwiftCrossUI implementation and I've been able to replace so many ugly gyb-generated repetitive definitions with clean and succinct variadic definitions.

1 Like

Apologies, the implementation note should probably say something more like "partial" given that, as you noted, it still is with the earlier .element syntax. The work to drop that syntax is underway but not yet complete. Glad to hear that this will be useful for you and the specifics about that!

1 Like

It would be self-evident, but is the order of execution is stable? In other word, if repeat print(each tuple), execution must start from the first item and end with the last item in the tuple, right?

Since the elements in an abstract tuple are the value pack, this becomes a more general question of all packs as specified by SE-0399, and yes the order of expansion is sequential and stable.


Thanks for participating in this review; the language steering group has decided to accept this proposal.