Add static typing for loop variables in for loops

[ttencate]

Describe the project you are working on:

A Zachtronics style puzzle game, using static typing as much as possible.

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

My code does a lot of work with Arrays, which contain objects that are all the same type. This is extremely common with arrays in general; I've rarely seen use cases for arrays containing completely arbitrary types. There's almost always at least a common base type for all elements.

When looping over the Array with a for loop, the docs explicitly state that you can't specify a type. This is forbidden:

for name: String in names:
    ...

So inside the loop body, name will be untyped, even if we know we started out with an array of Strings. We'd prefer to fail with a clear error if that assumption is ever violated.

The reason, according to the docs, is:

You can’t force the assignment of types in a for loop, as each element the for keyword loops over already has a different type.

That's a nonsensical argument; in other places (e.g. simple variable assignments) it's entirely possible assign values of unknown types to variables that have a static type:

var foo = 0
var bar: String = foo  # Fine at compile time, error at runtime.

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

Allow syntax like the above:

for name: String in names:
    ...

It would check the type at runtime and throw the usual error if it doesn't match:

Trying to assign a value of type 'whatever' to a variable of type 'String'.

Within the body of the for loop, name would have the type String and provide autocompletion and other static type checks accordingly.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

I would hope that it's fairly straightforward to add this to GDScript, but I've never looked at that part of the codebase before so I might be wrong.

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

One workaround is to live with a dynamically typed loop variable, at the cost of losing autocompletion and type checking in the editor.

The other workaround is to use a helper variable and cast it explicitly:

for temp_name in names:
    var name := temp_name as String
    ...

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

It's a core GDScript feature, so it cannot be implemented externally.

[Deftwun]

Godot noob & Just my 2 cents but this syntax would be awesome to get type hints inside for loops

for name in names as String:
    print(name)

I'd expect it to throw an error at runtime if types didn't match

[Calinou]

@Deftwun That syntax doesn't seem as readable as for name: String in names. Also, as has different semantics from : type hinting in GDScript.

[ghost]

I would also expect it to follow what it's doing currently.

for name : String in names:

[MatthewDLudwig]

Is there any progress on this proposal? Given that we can't use type hints with arrays (though the pooled arrays exist for some types) being able to specify what type we expect to be looping through would be helpful in terms of editor auto-suggestions.

[ScrewTSW]

What's the plan for this proposal?
It would be a really valuable Quality of life improvement

[katoneko]

4.0, AFAIK, will get typed arrays and dictionaries, so, bearing that in mind, is it necessary to specify the type of the loop variable when it can be inferred (at compile time!) from the container items' type? Not against this proposal though, just a thought.

[Calinou]

@katoneko Typed (Variant) arrays are planned for 4.0, but I'm not sure if typed dictionaries will also be added in 4.0 as they are more difficult to implement.

[mounirtohami]

this works for me , it may help for type hints since var button := _button will print an error of unknown type

for _button in buttons:
    var button : Button = _button
    button.align = ALIGN_CENTER

[mleidl]

This will give you the code hinting at least, and it makes sure it's of that type:

for button in buttons:
    if button is Button:
        button.align = ALIGN_CENTER

[Calinou]

This will give you the code hinting at least, and it makes sure it's of that type:

for button in buttons:
    if button is Button:
        button.align = ALIGN_CENTER

This fails silently at run-time if the type doesn't match, so beware. A safer alternative for debug builds is:

for button in buttons:
    assert(button is Button)
    button.align = ALIGN_CENTER

[PoisonousGame]

Hope to implement soon! It might now be possible to write:

for button in buttons:
    button = button as Button
    button.align = ALIGN_CENTER

I don’t know which way is better?

[aXu-AP]

I just wanted to propose this exact thing with the same arguments, as well. I find myself from time to time trying to write for loops with static typing just to remember it cannot be done.
I think it would do a lot for consistency of gdscript and feel totally natural to use static typing in every place we can declare variables.

[Daylily-Zeleen]

@katoneko Typed (Variant) arrays are planned for 4.0, but I'm not sure if typed dictionaries will also be added in 4.0 as they are more difficult to implement.

I hope typed dictionaries can be implemnted in 4.0, I think it is as important as typed arrays. I can't find a proposal about typed dictionaries, but it is obviously that typed dictionaries can bring benifits which the same as typed arrays, and I think core developers have realized that. So I don't know whether a proposal should be submitted.

[raulsntos]

@Daylily-Zeleen A proposal for typed dictionaries already exists: #56

[Daylily-Zeleen]

@Daylily-Zeleen A proposal for typed dictionaries already exists: #56

Thanks, hope it can be implements as soon as possible.

[Calinou]

Thanks, hope it can be implements as soon as possible.

Typed dictionaries are not planned for 4.0 due to time constraints, but they may be implemented in a future 4.x release.

[nautmeg]

Has anyone heard any news on typed for loops? Would like to see that implemented, although as some have said already it isn't difficult to add a new typed variable and assign the value of the for loop item to it... just seems a bit unnecessary. Also, I'm thinking when iterating larger objects, creating a new instance and assigning the looped item to it could be expensive... I can't say that's been an issue particularly for me as I wouldn't normally have a large set of large objects to loop through but it may be detrimental for some.

[oparisy]

I guess such "intermediary typing variables" would be references to objects and not copies, so the cost would not depend on their size? Le mer. 15 juin 2022, 13:39, nautmeg ***@***.***> a écrit :

…

Has anyone heard any news on typed for loops? Would like to see that implemented, although as some have said already it isn't difficult to add a new typed variable and assign the value of the for loop item to it... just seems a bit unnecessary. Also, I'm thinking when iterating larger objects, creating a new instance and assigning the looped item to it could be expensive... I can't say that's been an issue particularly for me as I wouldn't normally have a large set of large objects to loop through but it may be detrimental for some. — Reply to this email directly, view it on GitHub <#632 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGGPMIKC4EPV3TKYJVTH5LVPG6GXANCNFSM4LTS5T7A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[4CoDev]

Why specify a type for "name" if it has the same type as "names"?

[oparisy]

OO-wise I can imagine wanting to specify for "name" a type higher in the inheritance hierarchy that the one deduced from "names". To write more generic code, prefer an "interface" instead of a complex, concrete class, this kind of things. Le sam. 18 juin 2022, 21:43, 4CoDev ***@***.***> a écrit :

…

Why specify a type for "name" if it has the same type as "names"? — Reply to this email directly, view it on GitHub <#632 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGGPMOGIWOPXRDESRB5PXDVPYRHFANCNFSM4LTS5T7A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[OffsetMOSFET]

Hope to implement soon! It might now be possible to write:

for button in buttons:
    button = button as Button
    button.align = ALIGN_CENTER

I don’t know which way is better?

I'm able to infer the type without assignment (align should be recommended).

for button in buttons:
  button as Button
  button.align = ALIGN_CENTER

edit: this also works

for button in buttons:
  button is Button
  button.align = ALIGN_CENTER