Proposal: Variadics

[geoffromer]

Proposes a set of core features for declaring and implementing generic variadic
functions.

A "pack expansion" is a syntactic unit beginning with ..., which is a kind of
compile-time loop over sequences called "packs". Packs are initialized and
referred to using "pack bindings", which are marked with the each keyword at
the point of declaration and the point of use.

The syntax and behavior of a pack expansion depends on its context, and in some
cases by a keyword following the ...:

• In a tuple literal expression (such as a function call argument list), ...
  iteratively evaluates its operand expression, and treats the values as
  successive elements of the tuple.
• ...and and ...or iteratively evaluate a boolean expression, combining
  the values using and and or, and ending the loop early if the underlying
  operator short-circuits.
• In a statement context, ... iteratively executes a statement.
• In a tuple literal pattern (such as a function parameter list), ...
  iteratively matches the elements of the scrutinee tuple. In conjunction with
  pack bindings, this enables functions to take an arbitrary number of
  arguments.

[josh11b]

I made another pass without diving into the type checking bits, since those seem like something that could be handled in a separate proposal once the other issues are handled.

[josh11b]

(Sorry, I haven't searched for the right place to put these issue threads.)

[josh11b]

Issue: each(>=1) syntax

This issue I'm more neutral on, but I think it is extra complexity we don't need if we don't have restrictive matching. It means that there is additional syntax to learn, more ways to write function signatures, and those ways are subtly different in ways that are hard to explain. It also has concerns around which each needs to be marked with (>=1) and extra round trips if the user gets it wrong.

[josh11b]

Perhaps include this rationale in the "No parameter merging" alternative?

[geoffromer]

It means that there is additional syntax to learn, more ways to write function signatures,

OK, I've added those points.

and those ways are subtly different in ways that are hard to explain.

I don't agree with this one:

fn F[A:! I, ... each B:! I](a: A, ... each b: each B);
fn G[A:! I, ... each B:! I](... each b: each B, a: A);
fn H[A:! I, ... each B:! I](... each b: each B, a: A) -> A;

Under the primary proposal, F and G are equivalent (in terms of the requirements they impose on the argument list), but G and H are different. Under this alternative, F and G are different, but G and H are equivalent. I don't know how to convincingly argue that the latter state of affairs is any more subtle or hard to explain than the former. If anything, it seems easier to explain, because there's a direct (but perhaps unexpected) connection between the signature syntax and the callsite requirements.

It also has concerns around which each needs to be marked with (>=1) and extra round trips if the user gets it wrong.

This seems like a corollary of the fact that (>=1) conceptually belongs on ... rather than each, which is already discussed in the rationale.

[msadeqhe]

What's your opinion if we could have generalized binary operator expansion in addition to and and or?

... and each item
... or each item
... + each item
... * each item
... << each item

...>=1 and each item
...>=1 or each item
...>=1 + each item
...>=1 * each item
...>=1 << each item

If >= has lower precedence than other operators, maybe it could be removed for consistency:

...1 and each item
...1 or each item
...1 + each item
...1 * each item
...1 << each item

Also the expand keyword puts comma between them, and , could mean expansion:

... , each item
...1 , each item

What's your opinion?

EDIT: Now I've read your alternative section about fold expressions. Thanks for the information.

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active, please comment or remove the inactive label.

This PR is labeled inactive because the last activity was over 90 days ago. This PR will be closed and archived after 14 additional days without activity.

[josh11b]

Looking good! I really appreciate the examples you have included, they are quite helpful (and so I've asked for even more!).

[josh11b]

Looking good! I think this is ready for leads review.