Add a opt-in GDScript warning when type inference is not used where it could be (and vice versa)

[Calinou]

Related to #173, #3283 and #3531.

Describe the project you are working on

The Godot editor 🙂

Describe the problem or limitation you are having in your project

There are several schools of thought when it comes to type inference in a programming language:

• According to some people, type inference saves typing and doesn't remove much information that you can't otherwise gather by reading the code.
• According to others, type inference reduces readability by stripping explicit type information from the source files. This makes online code reviews harder as you don't have access to IDE-provided documentation there. (For the record, this is why auto is not allowed in Godot's C++ codebase.)

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

Depending on people's code style preferences, it may be useful for a project to enforce the use of one of 3 styles:

• Always use type inference whenever possible. Types should be written explicitly only if the type can't be inferred.
• Never use type inference.
• Don't warn about type inference (default).

If the existing "Turn Warnings To Errors" project setting is enabled, then an error is emitted instead.

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

• Add an enum project setting to adjust this new warning.
• Implement the warning in the GDScript analyzer.

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

No, as GDScript warnings are emitted by the GDScript language implementation itself.

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

See above.

[aaronfranke]

Depending on people's code style preferences, it may be useful for a project to enforce the use of one of 3 styles:

Another option: Use type inference when the type keyword is already written on the line. This is what Godot uses for its internal C# code for the style guide for the var keyword. For example (GDScript):

# Obvious enough, the line already has Vector3, no need for ": Vector3 = Vector3"
var vec := Vector3.ZERO
# 0.0 does not contain the word "float", so explicitly typing is enforced.
var x: float = 0.0
# While the word "Node" is written on the line, that's a NodePath, not a type keyword.
@onready var node: Node = $Node

[akien-mga]

For detail, we discussed this and approved the idea. There is a PR that implements something along those lines, but we're not fully satisfied with the way it's implemented, so this will require more work: godotengine/godot#59428

[ryanabx]

we're not fully satisfied with the way it's implemented, so this will require more work: godotengine/godot#59428

What sort of work would need to be done to get this feature accepted? I'm looking at a few language feature proposals to try and implement and this is one I'm interested in

[Calinou]

What sort of work would need to be done to get this feature accepted? I'm looking at a few language feature proposals to try and implement and this is one I'm interested in

See these two comments: godotengine/godot#59428 (comment), godotengine/godot#59428 (comment)

[ryanabx]

See these two comments: godotengine/godot#59428 (comment), godotengine/godot#59428 (comment)

I implemented the warning (or a similar warning) in a new PR (godotengine/godot#81355) it's been discussed and approved in today's GDScript meeting :)

[dalexeev]

The PR does not close this proposal completely, it only adds a warning if there is no hard static type. We need another warning in case there is no explicit type (datatype_specifier == nullptr).

Not sure if this warning should affect constants (since they are always have static types and their values do not change) or if we need a third warning for that. Probably such configurability is redundant and 3 levels of static typing are enough: 1. optional, 2. required hard type, 3. explicit type specifiers.

[ryanabx]

The PR does not close this proposal completely, it only adds a warning if there is no hard static type. We need another warning in case there is no explicit type (datatype_specifier == nullptr).

Not sure if this warning should affect constants (since they are always have static types and their values do not change) or if we need a third warning for that. Probably such configurability is redundant and 3 levels of static typing are enough: 1. optional, 2. required hard type, 3. explicit type specifiers.

I agree that having an explicit typing warning would not be a bad idea, for the extra hardcore static typing users out there ;)