language icon indicating copy to clipboard operation
language copied to clipboard

Obtaining a tuple of actual function arguments

Open tatumizer opened this issue 5 years ago • 3 comments

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 avatar Nov 07 '20 21:11 tatumizer

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.

lrhn avatar Nov 09 '20 14:11 lrhn

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 avatar Jan 25 '22 19:01 munificent