Godot: packing and unpacking lists -> variable argument count for functions

[curly-brace]

like in python:

func myCoolFunc(first_arg, second_arg, *rest_args):
...

we can pass variable count of arguments to this function and inside of this function they could be taken from a list in normal way by indexes. but first two arguments will be accessed like normal variables

variable count could be usefull here if we need to call different functions from this very function depending on say first arguments.

var result = obj.myCoolFunc(12, 42, 555, 666, 999, 1024, 'may be even a string?')

and we can call the function from this function by just using:

...otherFunc(*rest_args)

but the main reason: we will also be able to pass arguments to normal functions like this:

my_sprite.set_pos(*my_list_with_arguments)

that will unpack the list into positional arguments of the function and if the length is greater then the count of arguments, remaining will be ignored.

this all will lead to a more convenient way to use FuncRefs, like creating a timer system using simple list, that will contain just a funcref and a list of arguments you want to pass to that function upon call

and as a more complex suggestion: add dictionary support too, with **
this will allow to pass dictionaries with named arguments to functions and get arguments by their name from dictionaries

[bojidar-bg]

What about using .. instead of unary *? E.g.

func abcd(a, b, c, d, ..efg):
# Or:
func abcd(a, b, c, d, efg..):

## Then

abcd(..array)
# Or:
abcd(array..)

This would also allow us to reuse the token for range short notation (worth another issue if found valuable):

for i in [0..100]:
# for i in range(0,100)

[curly-brace]

dunno how you're gonna reuse this for range notation, but seems like .. is better then *, because there would be no confusion with pointers notation (personally i was first confused with python syntax of this)

[bojidar-bg]

(For the record, my propsal is inspired by.... CoffeeScript's "splat" syntax)

[ghost]

related to #7584

[akien-mga]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!