-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Variadics #2240
base: trunk
Are you sure you want to change the base?
Proposal: Variadics #2240
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Also respond to some early design feedback
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Sorry, I haven't searched for the right place to put these issue threads.)
in that sense this proposal may actually support that principle. | ||
|
||
## Alternatives considered | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps include this rationale in the "No parameter merging" alternative?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
What's your opinion if we could have generalized binary operator expansion in addition to ... 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 ...1 and each item
...1 or each item
...1 + each item
...1 * each item
...1 << each item Also the ... , each item
...1 , each item What's your opinion? EDIT: Now I've read your alternative section about fold expressions. Thanks for the information. |
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 This PR is labeled |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! I really appreciate the examples you have included, they are quite helpful (and so I've asked for even more!).
Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! I think this is ready for leads review.
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 ofcompile-time loop over sequences called "packs". Packs are initialized and
referred to using "pack bindings", which are marked with the
each
keyword atthe 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
...
:...
iteratively evaluates its operand expression, and treats the values as
successive elements of the tuple.
...and
and...or
iteratively evaluate a boolean expression, combiningthe values using
and
andor
, and ending the loop early if the underlyingoperator short-circuits.
...
iteratively executes a statement....
iteratively matches the elements of the scrutinee tuple. In conjunction with
pack bindings, this enables functions to take an arbitrary number of
arguments.