Skip to content
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

Obtaining a tuple of actual function arguments #1295

Open
tatumizer opened this issue Nov 7, 2020 · 2 comments
Open

Obtaining a tuple of actual function arguments #1295

tatumizer opened this issue Nov 7, 2020 · 2 comments
Labels
feature Proposed language feature that solves one or more problems patterns Issues related to pattern matching.

Comments

@tatumizer
Copy link

tatumizer commented Nov 7, 2020

The issue of forwarding was raised on multiple occasions during dart history.
The tuple of actual arguments can help, it's just a matter of finding a good syntax. The first thing that comes to mind is $arguments:

myFunction(int a, int b, {String s=""}) {
   anotherFunction(...$arguments); // forwarding
   anotherFunction(...$arguments with (_, 10, "Hello"));
}

There's a related issue: how to declare tuple type based on the argument list of existing function?
I can't find any prior example of anything like that in dart. One obvious variant is:

typedef MyTupleType=someFunction.$arguments

which I don't like because it works (kinda) only in the context of typedef, but is no good as a type expression - e.g. this declaration is weird:

someFunction.$arguments myTuple; // variable of type someFunction.$arguments 

Another variant can be

(...someFunction.$arguments) myTuple;

but this is too fancy.

EDIT: If dart introduces compile-time macros like #nameOf(foo.bar) then the natural idea would be to define yet another macro for the function argument tuples, with a more articulate syntax

#tupleTypeOf(myFunction) tuple=(1, 2, s="hello");

or something to that effect

@tatumizer tatumizer added the feature Proposed language feature that solves one or more problems label Nov 7, 2020
@lrhn lrhn added the patterns Issues related to pattern matching. label Nov 8, 2020
@lrhn
Copy link
Member

lrhn commented Nov 9, 2020

I would love if noSuchMethod's Invocation had a tuple for the arguments, and not a pre-deconstructed list/map.

You'd need to know the structure in order to deconstruct the arguments, but you might be able to pass them on to something else in a dynamic call.

Allowing a function to access its own argument tuple as a tuple seems very reasonable.
If you see all functions as unary functions from a tuple type to the result type, and argument lists just being implicit pattern matches on the argument tuple, then that pattern match should also be able to name the entire tuple.

@munificent munificent reopened this Jan 25, 2022
@munificent
Copy link
Member

If it's OK, @tatumizer, I'll leave this open. We don't currently have plans to support this, but I think it's a reasonable and useful extension of our plans around tuples and pattern matching.

@munificent munificent added patterns-later and removed patterns Issues related to pattern matching. labels Aug 19, 2022
@munificent munificent added patterns Issues related to pattern matching. and removed patterns-later labels Aug 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Proposed language feature that solves one or more problems patterns Issues related to pattern matching.
Projects
None yet
Development

No branches or pull requests

3 participants