Allow users to choose if scripts should be forced to be statically typed (or not)

[dreamsComeTrue]

Describe the project you are working on:

Godot source code itself / RPG-type game in 2D

Describe the problem or limitation you are having in your project:

Having lot of GDScript files, I am not forced anyhow to maintain consistency across them.
Thus - I sometimes use optional typing, sometimes not.
I would love to have some sort of switch (on Editor Settings for example) that will force me
to remember to put types (or not) in Script files.

Describe how this feature / enhancement will help you overcome this problem or limitation:

Having scripts checked for using optional typing across whole files would set harmony across whole project.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

Describe implementation detail for your proposal (in code), if possible:

Probably (apart from Editor Settings changes) that would need a lot of modifications of script_text_editor.

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

Only, if team/developers agree to have one appointed way of writing scripts

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

It should have access to Script Editor itself (or some kind of background checker/code linter) - and as long as script_text_editor is a plugin itself - it could be also considered as a addon.

[KoBeWi]

It's basically like warning about unsafe lines, no?

[rainlizard]

When the planned speedboost for using typed-variables is implemented, I would definitely want to have this feature so everything can be consistently optimized.

[aaronfranke]

One big issue with this currently is that there are some pieces of code you can't write with static typing, such as if you need nullable value types. EDIT: #162

[Calinou]

If we want this to be implemented, we need to have an any type hint first, so that you can explicitly mark values as being dynamically typed.

Edit: This is now available in the master branch as the Variant type hint.

[bojidar-bg]

Note that such a setting should likely live in the Project Settings, since it should be the same for all team members working on a project.

[Jummit]

This looks like it could be a by default disabled warning.

[dreamsComeTrue]

It's basically like warning about unsafe lines, no?

Am I missing something - is there a magic switch for that? What I would like to achieve is one big list of all places in scripts where there is no type information which is dynamically updated as I am editing them. Currently, there is an Errors tab on Debugger pane, and it populates kinda similar data, but that happens only after I run the game (more like a debug output of all code places which were executed and had some problems). It is not being updated 'on the fly'.

[KoBeWi]

Am I missing something - is there a magic switch for that?

There's none. "Safe" lines are code with unambiguous and strictly static typing (so no dynamic stuff). Their numbers are marked in green-ish color. I guess if we implemented a warning about unsafe lines, it could be enough for this proposal. Although there are some cases where some lines are marked as "unsafe" when they shouldn't.

[fab918]

I don't know if I should post a dedicated proposal but I want to extend your proposal to resolve your issue: keep the best of the two-word and switch to a (semi) typed language.

There are practically only advantages that will help beginners and advanced users:

• auto-complete
• keep consistency with tutorials and examples
• avoid bugs
• avoid bad designs
• increase the maintainability (especially for a serious project)
• performance (one of the main complain about GDScript, people don't want to learn GDNative)
• etc.

The main drawback is the extra syntax, but that's why I say "semi typed", the magic of GDscript is to be able to make type inferences in most of the situation. In other words, the language can be "typed" without writing any types in code in most of the case, so why keep this inconsistency? The gain of performance and maintainability will be a game changer for (semi) pro-users and the compilation errors will helps especially beginners.

[aaronfranke]

@fab918: The main drawback is the extra syntax

The main drawback is breaking backwards compatibility. This likely won't happen even though I personally think it's a good idea.

[fab918]

@aaronfranke Godot 4 will be a major release, major release can have breaking changes if the benefits worth it. Maybe a survey on this, explaining the stakes, can be a good option!?

Moreover, a typed language doesn't mean you can't have untyped variable (but not by default). If you set an any type like Typescript, you can probably convert old code to new one without breaking changes.

It's a shame to have to choose between fun and fast syntax (GDscript) or robust language (c++/c#) when GDscript can be both.

[Calinou]

Godot 4 will be a major release, major release can have breaking changes if the benefits worth it. Maybe a survey on this, explaining the stakes, can be a good option!?

We already have some compatibility breakages planned for 4.0. We don't want to add too much of them to avoid ending up in a situation like Godot 3 where many people never migrated to it. This is especially true due to the new rendering engines coming in Godot 4, which most people will benefit from.

I also proposed adding an any keyword above. Combining it with a project setting that requires everything to have a type annotation is likely sufficient (like TypeScript's noImplicitAny).

• performance (one of the main complain about GDScript, people don't want to learn GDNative)

Typed instructions can likely be implemented without requiring type hints to be used everywhere. Of course, the more type hints you add, the better the speedup will be 🙂

[fab918]

I also proposed adding an any keyword above. Combining it with a project setting that requires everything to have a type IF THE TYPE IS NOT INFERABLE annotation is likely sufficient (like TypeScript's noImplicitAny).

I added few words to your quote I think they are important. If your assertion on performance optimization is correct, it's a good balanced solution (I think it's important if this box is checked by the default to promote best practice for users, especially beginners).

[Calinou]

@fab918 Of course, the point of the setting isn't to forbid type inference. I like my := assignments too 🙂

That said, I'd say it's a bad idea to make = automatically infer the type as it'd change how the language would behave depending on project settings.

[fab918]

That said, I'd say it's a bad idea to make = automatically infer the type as it'd change how the language would behave depending on project settings.

@Calinou we are near to be 100% agreed :)

I understand the principle, but forasmuch it's only for a hint, is it a really problem? Because the alternative is to be forced to use an heavy/useless syntax
:= (especially if this setting become the standard in the community, what I'm pretty sure it will be when the performance optimization will be available). And in term of principles, a useless syntax is against the spirit of GdScript / Python.