Design meeting: Variadic Generics

[tomassedovic]

Summary

Variadic generics is a feature that's desired by many but it's a design an implementation minefield (see https://poignardazur.github.io/2025/07/09/variadic-generics-dead-ends/).

@PoignardAzur has been talking to people and investigating the various approaches and the lang team feels now's a time where they may have capacity to consider a design seriously. It also seems most of the blockers for this effort have now either been lifted or have an end in sight (e.g. the next trait solver).

@PoignardAzur will put together an RFC which the lang team will read and discuss.

cc @PoignardAzur @oli-obk @alice-i-cecile @PROMETHIA-27

Background reading

Include any links to material that folks ought to try to read before-hand.

About this issue

This issue corresponds to a lang-team design meeting proposal. It corresponds to a possible topic of discussion that may be scheduled for deeper discussion during one of our design meetings.

[tomassedovic]

To everyone interested in this feature: @PoignardAzur posted this small survey: https://blog.rust-lang.org/inside-rust/2025/09/22/variadic-generics-micro-survey/

Everyone, please respond to it if you can. It asks for your use cases and specific features. Collecting that feedback will be really valuable. It's open until 2025-10-20

[weiznich]

I was asked to also post this comment here. The comment below is a literal copy out of this zulip thread:

---

Hi there, as this now seem to mostly devolved into a thread about variadics instead of bevy only stuff I hope it's fine to add some non-bevy perceptive here as well.

I already filled out the survey but I have quite a few thoughts and observation that don't really fit there.

First of all diesel is using macros for a long time (~since the beginning, longer than proc-macros are stable) for emulating variadics for various uses. Most uses are in this particular file in our code base, although there are several other places as well. All of them use the __diesel_for_each_tuple! macro to generate the various instances. We generally implement all these traits for tuples up to 32 elements by default and provide feature flags for sizes up to 128 elements. The largest size has a quite serve impact on the compile time of diesel itself, the last time I actually build that it took something like 10 minutes. Still even with that we get requests form time to time to support even large tuple sizes, as these directly relate to how many columns your table is allowed to have. If you would like to have more information about particular usages I'm also happy to provide more details.

So now to the in my opinion more relevant things. The first observation I would like to share is that at least from my point of view the existing system for writing these implementations is working mostly fine. For me the actual problems are less around writing those impls (sure that's nasty and you need to do strange macro stuff and so on), but more around:

1. Impact on the generated errors our users face if something goes wrong
2. Compile time impact due to all the generated code
3. Discoverability for users which traits are actually implemented by which tuple sizes, etc.

I feel that teaching "the compiler" about variadic generics might help to solve most/all of these points as well. On the other hand I'm not totally sure if we need real variadics for all of them or if at least some of them couldn't be solved in a much more simpler way. To bring some more specific examples here:

• Rustdoc has for example an internal #[doc(fake_varidic)] attribute that works for "some" tuple impls. It generates something like that. In turn it allows to hide most of impls for different sizes by having such a generic thing in the documentation. Obviously that's not perfect yet as it's internal (not even documented, so you really need to know about this), it doesn't display a maximum tuple size and it doesn't work in more complex cases.
• #[diagnostic::do_not_recommend] helps you to sometimes hide these impls from the error messages. Which can be helpful, but certainly it should be possible to do better than that by actually teaching the diagnostic system about what are variadics. Esteban started something here. Possibly this can be covered by another attribute in the diagnostic namespace to point the compiler in the right direction.

For compile times I honestly do not see an easy solution. I feel the problem there is essentially that we need to generate all implementations up front even if the user only ends up using the impls for size 1, 3,5 and 128. Sure clever caching or turning everything into a pull based compiler could possibly helps, but all that sounds like a really large project. Possibly that should also be a major point when designing how actual variadic are supposed to work.

I decided to explicitly write down these things, because at least some of that sounds like something that's one or two orders of magnitude easier to design, land and stabilize than variadic generics itself. On the other hand I believe it would still have a significant impact on exactly the use-cases targeted by variadic generics and also already provide some infrastructure in various compiler parts for future implementations of actual variadic generics. That all shouldn't stop anyone working on actual variadics, they still would be very much welcome. It's just that we waited now for nearly 10 years, so waiting a few more years won't hurt us that much if these other issues are tackled in the mean time.

Finally I would like to throw another idea into the void. This somewhat circles back to how diesel is emulating variadics today. We have a macro that essentially just generates sets of identifiers for us. These identifiers are then passed to a macro which generates the actual implementations by repetition of the provided identifiers. I wondered whether it might be an idea to "just" have the compiler provide such a generator. Sure, that somehow sounds like a hacky solution as it requires an explicit compiler magic thing. On the other hand I guess any variadic implementation will require one or more compiler magic things. Such a pattern would allow to compiler to only instantiate actually used variadic impls. So instead of generating all of the impls up to 128, we could only generate the ones for 1,3,5 and 128 elements. Such a pattern certainly would require some careful handling about what such impls are allowed to rely on (e.g. any required impl on a tuple containing at least one generated identifier must be generated by another "macro" call as well). Also I'm not sure how helpful this would be for "recursive" impls (such delegating to a tuple with n-1 elements). By no means I would expect that to be a perfect solution, it's just something that came up while thinking about this.