You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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.
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
: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:
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:
Another variant can be
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 syntaxor something to that effect
The text was updated successfully, but these errors were encountered: