Describe the project you are working on:
Reaction game
Describe the problem or limitation you are having in your project:
I can't use an argument in the function defining line (line that begins with func) for another argument.
This works:
var number1 = 1
var number2 = number1 + 10
func _ready():
my_function(number1, number2)
func my_function(argument1, argument2):
print(argument1 + argument2)
prints 12
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
You could do something with argument1 in argument2.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
This does not work (yet):
var number1 = 1
func _ready():
my_function(number1):
func my_function(argument1:int, argument2:int=argument1 + 10):
print(argument2)
Would print 12
If this enhancement will not be used often, can it be worked around with a few lines of script?:
Not sure, see below
Is there a reason why this should be core and not an add-on in the asset library?:
Useful for every project.
If this enhancement will not be used often, can it be worked around with a few lines of script?:
Yes
In this case, this means we most likely don't need to implement a new feature in core (which we need to spend time maintaining and supporting).
:(
But wait, you could do print(argument1 + 10) but this is not exactly the same because you'd have to do something with argument1 everywhere where you would use argument2, so maybe my answer "Yes" is wrong.
Your "yes" answer is correct. One could simply do the following.
# -1 can be some other value that you'd never input
func function(arg1:int, arg2:int = -1):
arg2 = arg1 + 10 if arg2 == -1 else arg2
print(arg2)
Oh yes you are right. But this doesn't say it wouldn't be nice if my suggestion would be implemented ;D
But this doesn't say it wouldn't be nice if my suggestion would be implemented ;D
As I said above, there's a cost to every feature, even if it's not used often. See Best practices for engine contributors in the documentation.
Note that JavaScript supports this:
function x(a, b = a + 10) {return a + b}
x(1) // 12
But Python doesn't:
def x(a, b = a + 10): return a + b # NameError: name 'a' is not defined
This is due to the fact that in JavaScript default argument values are determined at call time, effectively becoming something like this (note that JavaScript every unspecified argument is undefined):
function x(a, b) { if(b == undefined) b = 10; return a + b }
While in Python, default argument values must be determined at definition time, even preserving object references, as in this popular example:
def f(a = []):
a.append(1)
return a
f() # [1]
f() # [1, 1]
In GDScript, default arguments are computed when the function is called:
var x = 0
func f(a = x):
return a
func _ready():
print(f()) # 0
x = 4
print(f()) # 4
Therefore, the restriction that default argument expressions cannot use previous arguments seems a bit arbitrary, likely originating in the parser not allowing it, as opposed to the compiler/runtime not allowing it.
Having funtion polymorphism could be a good workaround killing two birds with one stone:
func my_function(argument1):
return my_function(argument1, argument1 + 10)
func my_function(argument1, argument2):
# doStuff
I'm proposing it here because I couldn't find any issue about it and I don't want to bother anyone since it should probably have been answered somewhere else.
IDK if it can help to do quickly what you wanted to do nicely, or if it is even relevant to add it to an interpreted language tho.
This works:
var number1 = 1 var number2 = argument1 + 10 func _ready(): my_function(number1, number2): func my_function(argument1, argument2): print(argument1 + argument2)prints 12
Wait, does this really work? In which Godot version this work? I can't see how because members are evaluated when they are declared not when they are used. Tested with 3.2.2 beta and it doesn't compile. Or maybe that's how you want it to work?
@bojidar-bg
Therefore, the restriction that default argument expressions cannot use previous arguments seems a bit arbitrary, likely originating in the parser not allowing it, as opposed to the compiler/runtime not allowing it.
Indeed that seems to be the case. With a dirty test here I saw that it works. Naturally it only really work when using arguments from the left. Using the ones on the right gets them still undefined. I think it's fine to allow that since the current barrier is only parsing.
Oh sorry, I made a mistake. I'm going to change it how it works.
Having funtion polymorphism could be a good workaround killing two birds with one stone:
func my_function(argument1): return my_function(argument1, argument1 + 10) func my_function(argument1, argument2): # doStuff
maybe this is another "pro" for having this feature
as for the given topic with javascript style arguments, I am not sure if it would improve my codebase significantly.
Most helpful comment
Note that JavaScript supports this:
But Python doesn't:
This is due to the fact that in JavaScript default argument values are determined at call time, effectively becoming something like this (note that JavaScript every unspecified argument is
undefined):While in Python, default argument values must be determined at definition time, even preserving object references, as in this popular example:
In GDScript, default arguments are computed when the function is called:
Therefore, the restriction that default argument expressions cannot use previous arguments seems a bit arbitrary, likely originating in the parser not allowing it, as opposed to the compiler/runtime not allowing it.