Closed robamu closed 6 months ago
This is probably really tricky because a lot of the other API relies on T being one argument. For bevy, there are also constraints on the possible input parameter types, so I don't know how applicable that is for this case.
UPDATE: This little test seems work. So in principle, this probably is possible, but the T argument now becomes a marker trait and the function arguments are specified by an associated argument.. so this is definitely a major breaking change..
This was considered but ultimately abandoned for a couple of reasons:
Scheduler
argument compulsory, otherwise there would be an ambiguity between a 2-arguments input method without scheduler argument and a 1-argument input method with a scheduler argument; since the Scheduler
argument is frequently unused, it was felt that this was the better trade-off,Output::send()
and this mix of conventions could be confusing, unless multi-arity alternatives like Output::send2()
, Output::send3()
are introduced, which I personally find not very palatable (the same goes for Simulation::schedule_event*
etc.),Also, it makes it possible to add other optional arguments than Scheduler
in the future.
Sounds reasonable. You can close this issue :+1:
I had an input function like this:
and had to rewrite it as:
Did I do something wrong or is the number of additional arguments constrained to 1? it would be nice if I could instead use the initial version. This probably would be possible by implementing
InputFn
for a certain number of arguments. I saw a similar thing done inside thebevy
game engine to allow magically passing functions with a higher number of arguments to the engine: