Variadic tuples

[fredericvauchelles]

This RFC introduce variadic tuples, and API to handle tuples with an arbitrary arity.

Rendered
Internal's thread

[fredericvauchelles]

A small update concerning the feedbacks received. First thanks for your feedbacks, I will take them into account, as they are a lot of them I will process them over several days.

Cons-list

As suggested I looked at other RFCs and focused mostly on cons-list proposals (like #2702).

To do so, I wrote some use case with both RFCs (https://gist.github.com/fredpointzero/7b40e93d3e2226ca4aec00fdd1bc3e20).

Note: I used a less gross syntax for the variadic tuple RFC, by using

for (k, map), (Key, Value) in (&k, &self.maps), (K, V) {
    HashMap::<Key, Value>::get(&map, k)
}

// Instead of
for (k, map) <Key, Value> @in (&k, &self.maps) <K, V> {
    HashMap::<Key, Value>::get(&map, k)
}

What I found is:

1. The RFC I suggested includes cons-list as well. (See Rev implementation) so this is as expressive as cons-list proposals
2. A lot of implementations can be implemented only with cons-lists (See Hash, Merge, Zip, ...)
3. Some implementations can't be implemented or are very difficult to implement with only cons-lists (See MegaMap, Split)
4. This RFC is probably more complex to implement in Rust language than other proposals

So, in my opinion, both cons-list and iterative patterns must be available to use when considering variadic tuples.

I haven't looked at hlist yet, but I will do later.

Clarity of the RFC

The current document is not clear and I will first focus on making it easier to understand. Mostly the guide-level section.

For loop syntax

I am not fan of the syntax as well, and still will try to come up with something better.

A little note here, although the feature is powerfull enough without the variadic tuple iteration, I prefer to make sure that the variadic tuple iteration is possible, at least in future possibilities. In my opinion, this is required to implementent some features easily.

And a quick suggestion here, to have something less gross we can use the syntax suggested above.
Or also, as the issue is about iterating through two kinds of variable (variadic tuple members and variadic tuple type members) we may use two for loops, like:

for (k, map) in (&k, &self.maps)		// variadic tuple
for (Key, Value) in (K, V) {			// variadic tuple type
    HashMap::<Key, Value>::get(&map, k)
}

// Instead of
for (k, map) <Key, Value> @in (&k, &self.maps) <K, V> {
    HashMap::<Key, Value>::get(&map, k)
}

[the8472]

Is &Tail a reference to the tail or a tuple of references? The former would prevent currently performed struct layout optimizations, see rust-lang/unsafe-code-guidelines#105 for more details. The latter would be costly since could require a lot of intermediate values on the stack.

[RustyYato]

It's a tuple of references.

[fredericvauchelles]

A quick update on this, I need to handle an unfortunate private event, so I pause my work here and resume it in a few weeks

[nico-abram]

@fredpointzero It's been a few weeks, could you provide any status updates? I'm just a slightly too curious onlooker :P

Thank you for your work so far.

[fredericvauchelles]

@nico-abram Unfortunately, I don't think I will be able to have enough spare time now to work on this PR, so I do not plan to work on it in the near future.

I'll be glad if someone could continue this PR

[nikomatsakis]

Hello,

We discussed this RFC recently in the lang team's backlog bonanza effort. The idea of variadic generics is one that has come up a number of times. It's a feature we would like to have, but at the same time, one that we feel like will require some significant bandwidth on the lang team's part to do properly and we don't think the time is quite ripe for that. Therefore, we are going to move to close this RFC.

However, we do expect to pick up this topic again at some point, and when we do, it would be great if we have summaries of the various approaches that have been considered to solve it and what their strong/weak points were. To that end, we would like to strongly encourage @fredpointzero or others on this thread to help us in growing the "lang team design notes" section of the web site. The idea would be to prepare a PR rather like rust-lang/lang-team#52 which adds notes and links about variadic generics. If new ideas come up, then follow-up PRs could be added too.

Thanks to @fredpointzero and all the participants in this thread for the RFC.

@rfcbot fcp close

[rfcbot]

Team member @nikomatsakis has proposed to close this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[nikomatsakis]

@rfcbot reviewed -- I have checked the names of folks who were in the backlog bonanza meeting where we discussed this, at least to my recollection.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[dlight]

Why is this a close, and not a postpone like #2666 ?

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC is now closed.

[PoignardAzur]

@nikomatsakis It's not exactly what you asked, but I did a survey of variadic generics here: https://gist.github.com/PoignardAzur/aea33f28e2c58ffe1a93b8f8d3c58667