Allow disabling dynamic typing in gdscript on a per file basis

[atomicptr]

Describe the project you are working on

I'm building a systems heavy game, meaning lots of code that doesn't directly interact with the engine that highly benefits from using static typing as much as possible in order to preserve some sanity.

Describe the problem or limitation you are having in your project

Since static typing allows the developer to write better code (my bias maybe), it is preferable to use it as much as possible. It is however very easy to mess up by either using the wrong assignment operator (:= VS =) or just outright forgetting to add a type to a variable, function parameter or return type.

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

This feature would allow developers to write better code by making full use of static typing whenever possible. This also has the added benefit of helping developers to write more performant code after the proposed changes of #6031 are implemented.

In case of missing typing or dynamic assignments the engine would refuse executing a marked script and print out an error.

The reasoning behind doing this on a per file basis is otherwise this would interfere with the usage of other Godot scripts (for example from an addon) or maybe the developer wants to mix and match like in this fictional scenario: Write a rough first implementation of a feature using dynamic typing (higher productivity) and then when improving the script disable dynamic typing, which enables the developer to quickly find and adjust the undesired code pieces.

There is currently at least one limitation of this proposal, the contents of collections are presumably using dynamic typing see #1207. Should that proposal be implemented a collection without specifying types should also be counted as an error. Same goes for #782 and probably other cases.

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

In order to mark a script as this proposal advocates for the addition of a new script annotation (assuming this is the correct name for this) similar to @tool named @strict (unless there is a better name):

# Annotating a script to be in strict mode which will disable the use of static typing
@strict

# the parameter x doesn't declare a type therefore resulting in an error
func my_function(x) -> void:
    # OK
    var y: int = 5 
    # OK 
    var z := 10
    # Error
    var w = 15

    print(x + y + z + w)

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

No, but a similar behavior could be implemented in a linter.

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

This is proposal is a new gdscript language feature and is IMHO better served being in core.

[ryanabx]

See:
godotengine/godot#81355
godotengine/godot#82139

Both these changes allow you to enforce static typing as an error check.

This, however, doesn't enforce typed arrays.

[dalexeev]

Regarding a per file basis, see:

• Ignore warnings for multiple lines in GDScript #5906
• `@warning_ignore_start` and `@warning_ignore_restore` #5405
• GDScript: Add @warning_ignore_start and @warning_ignore_restore annotations godot#76020

But it is not possible to enable a warning for a file/region if it has been disabled in the Project Settings.

[atomicptr]

See:
godotengine/godot#81355
godotengine/godot#82139

Both these changes allow you to enforce static typing as an error check.

Hey, finally got around to test the 4.2 build and I'd say this solves the problem for me (beyond progressive implementation), but good enough!

Thanks for the work!

Dunno why I didn't find these in my initial research however.

This, however, doesn't enforce typed arrays.

I don't think that's even possible until a later date anyway 😂

[ryanabx]

Hey, finally got around to test the 4.2 build and I'd say this solves the problem for me (beyond progressive implementation), but good enough!

Thanks for the work!

Dunno why I didn't find these in my initial research however.

To be fair, I think these warning(s), being new, should be clarified in the documentation. I just created a docs pr for that.
See:
godotengine/godot-docs#8137