Disallow type inference for function parameters with default values in GDScript (but allow it elsewhere)

[Calinou]

Related to #3284.

Describe the project you are working on

The Godot editor 🙂

Describe the problem or limitation you are having in your project

Currently, using type inference for function parameters with default values in GDScript is allowed:

func some_function(a: int, b := 5):
	pass

There are a few concerns with using type inference for function parameters though:

• The type of the b parameter can change unexpectedly depending on the default value's type. This can cause issues when refactoring code as your functions' expected types can change without notice, which can break your code in difficult-to-track ways. While this also happens with local and member variables, I feel like this is not much of a problem there.
• This is rather minor, but when looking at the function declaration at a glance, it looks like b is not typed here. The : can be easy to miss depending on the font used. Again, this isn't much of an issue with member or local variables, but I think the stakes are higher when it comes to functions.

From a quick search, it seems that most programming languages don't allow using type inference for function parameters with default values.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Disallow using type inference in function parameters that have a default value assigned. Instead, types must be specified explicitly:

func some_function(a: int, b: int = 5):
	pass

This change would only apply to function parameters. Type inference would remain allowed in member variables and local variable declarations.

Writing types explicitly requires a bit more typing, but I feel like it's worth it as function parameters with default values aren't very common in the first place. They're certainly less frequent than member and local variables for instance 🙂

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

This change would only be made in Godot 4.0 to avoid breaking compatibility with existing projects.

If this enhancement will not be used often, can it be worked around with a few lines of script?

This is about changing GDScript's behavior to be more strict, encouraging people to write more robust code.

Is there a reason why this should be core and not an add-on in the asset library?

See above.

[name-here]

While it can certainly cause unexpected bugs to do type inference with ints and floats, that's true everywhere you can use type inference, including for variables. Every other case I can think of for type inference, like func thing(a := Vector3()), var is_enabled := false, or func find(path := "res://") is very clear and not particularly confusing (well maybe not that last one, but there's unfortunately nothing better than String for file paths")

My personal opinion is that it's just bad practice to do type inference with numbers, since it can cause so many problems if you get it wrong. But I wouldn't say that code that repeats information (ex. func thing(a: Vector3 = Vector3())) is any more "robust" than the shorter version—after all, isn't this why type inference was introduced in the first place?

int vs float types are generally a headache in any dynamically typed language that has both of them, since they do math in importantly different ways, they can be hard to tell apart, and if you're not careful you don't know which one you're working with (like if your function parameters aren't typed at all). I don't think there are any good, universal solutions to this problem, though a partial one might be something like disabling type inference for any number types.

[AaronRecord]

But I wouldn't say that code that repeats information (ex. func thing(a: Vector3 = Vector3())) is any more "robust" than the shorter version—after all, isn't this why type inference was introduced in the first place?

I think I agree. If it's more work to disallow it than to allow it then I'd probably just say leave it be, but I don't have any strong opinions about it.

[vnen]

I feel this is an arbitrary limit to create. I don't see the difference in type inference between member variables and function parameters. The same issues apply to both cases.

Nothing is stopping people of making this a code-style rule in their project and always use explicit types.