Add support for annotation blocks in GDScript

[SysError99]

Describe the project you are working on

Many HTML5 games that mainly execute GDScript, since I aim for portability and C# doesn't fit the use case. (Godot on HTML5 alone is already very heavy in size compared to any of JS-based game engines)

Describe the problem or limitation you are having in your project

I personally prefer everything that runs in a single script, and treating child nodes as more like "data" rather than composition. I tend to prepare every node in on-ready time in which the script can get access without getting nodes again. In which, Godot already provided @onready annotation keyword, which is very nice and makes code cleaner. However, when nodes become pile-up more and more (which is quite normal for the code that treats child nodes as "data") typing @onready over and over again becomes tedious and time-consuming task (excluding the case of code-typing assistants). This also applies to other annotations that may require the same repetition.

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

Since @onready is one of killing feature over any of the programming languages supported in Godot, both officially and unofficially. Using annotation blocks will help with readability, maintainability, file size, and time-saving in overall code production.

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

Provide an annotation block feature that will consolidate indented lines into the same annotation. The snippet below will use @onready as an example.

@onready var a := 0
@onready var b := "Godot 4.0"
@onready var c := get_node("CanvasLayer/LabelTime") as Label
@onready var d := $ComplexTree/Row25/Col6/Label as Label
@onready var e := HTTPRequest.new()

Will become:

@onready:
    var a := 0
    var b := "Godot 4.0"
    var c := get_node("CanvasLayer/LabelTime") as Label
    var d := $ComplexTree/Row25/Col6/Label as Label
    var e := HTTPRequest.new()

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

I don't think this will be seldom used since it's a key feature of GDScript. Although I may be able to build another transpiler for GDScript, it's still not the same since GDScript is tightly integrated with the game engine.

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

It's directly related to GDScript, it cannot be solved unless I build my own programming language.

[Mickeon]

Since Godot 4 turns onready into an annotation @onready this can probably be expanded to be applicable to all annotations. I remember this behaviour being suggested in the original proposal #828.

It's also not too dissimilar from what other programming languages let you do. Here's a snippet of source code.

[YuriSizov]

@Mickeon Annotations stack and are applied to the next statement that takes them. This won't work if you start mixing it with other annotations, like export ones. And making it work would make the code less intuitive at a glance.

Annotations also don't create block context, so this proposal won't be possible to implement with Godot 4 syntax. Not without a rework of annotations.

And IMO, as it doesn't save lines anyway, if you want a bit more organization, you can move assignments to the _ready method for example.

[KoBeWi]

You don't need to type onready since 3.5. Just drop the node from scene tree to the script while holding Ctrl.

[Calinou]

It's also not too dissimilar from what other programming languages let you do. Here's a snippet of source code.

I consider this to be a poor approach as it makes refactoring code harder. You can no longer be certain you're keeping the existing visibility of the member variable when moving code around.

We already have to suffer from poorer-than-usual code refactoring due to the use of indentation for syntax instead of braces – let's not make the problem worse 🙂

[YuriSizov]

I consider this to be a poor approach as it makes refactoring code harder. You can no longer be certain you're keeping the existing visibility of the member variable when moving code around.

Actually, I have to agree, based on my work on the engine. It's often hard to figure out which scope the member has because you need to scroll up and down to find the statement that sets it. It has been quite annoying to me when refactoring some Control and Window code just recently.

[SysError99]

You don't need to type onready since 3.5. Just drop the node from scene tree to the script while holding Ctrl.

This could be specific but I don't code on Godot's code editor (I use Visual Studio Code), in which the approach isn't favourable in my case.

[hilfazer]

It's also not too dissimilar from what other programming languages let you do. Here's a snippet of source code.

I consider this to be a poor approach as it makes refactoring code harder. You can no longer be certain you're keeping the existing visibility of the member variable when moving code around.

Or the opposite - it could make refactoring easier e.g. for people following official GDScript's style guidelines. I'm moving a method from my protected section to my private section - yup, i want it to have its access modifier changed.

As for not knowing what's the access modifier of the code we're looking at - it's a solved problem.
I remember using some noname Java editor long time ago. It gave the code with different access specifiers different background colours. Godot Editor could do that as well or it could do something different like e.g. using different background colours just on the line numbers.

[Frontrider]

I believe we need to define how user annotations would work in GDScript, and consider this usecase for it.

[Calinou]

I'm moving a method from my protected section to my private section - yup, i want it to have its access modifier changed.

This tends to look confusing in VCS diffs unless the moved line of code is close enough to protected: or private:.

I remember using some noname Java editor long time ago. It gave the code with different access specifiers different background colours. Godot Editor could do that as well or it could do something different like e.g. using different background colours just on the line numbers.

Some external editors may not have this functionality, and we should avoid relying on IDE features being implemented to make something usable.

[shinspiegel]

Annotations also don't create block context, so this proposal won't be possible to implement with Godot 4 syntax. Not without a rework of annotations.

This is an important point to know.
I would never imagine that it was this level too tight with the line/proximity.
Considering the tab on the lexer I would imagine that this would be a simple feature to implement, but it does not look like it.

This is a feature that I would like to understand more about, I'm not a C++ dev, but with a little bit of guidance (aka.: put my face in the right direction) I could try to check what can be done and how to make this feature available.