onready should be a keyword not an annotation

[FeldrinH]

In Godot 4.0 beta, the onready keyword has been turned into the @onready annotation. I feel like there is a case to be made that this is confusing and inconsistent.

The documentation for GDScript clearly states about the semantics of annotations (reference):

Annotations affect how the script is treated by external tools and usually don't change the behavior.

In my opinion @onready violates both of these statements:

• Running something during node init or during _ready is a concern entirely internal to the node, so I would argue @onready does not affect how the script is treated by external tools.
• Running something during _ready instead of during node creation is a significant change to how the statement behaves, so I would argue that @onready does change behavior.

Given this, I propose changing @onready back into the onready keyword, like it was in Godot 3, as that would make it consistent with the stated distinction between annotations and keywords.

As an added bonus, this change would in my opinion improve readability, because onready is used a lot and I find having lots of @ symbols makes the code harder to read beacause of the visual noise it creates.

[dalexeev]

I think this is more of a bug in the documentation. For example, @export annotations affect the result of get_property_list() and the behavior of duplicate() (exported variables will be copied when duplicating a node/resource, unlike other variables).

The @rpc annotation has a very big effect on behavior too.

[FeldrinH]

I would still argue there is a meaningful distinction. The changes to behavior for @export and @rpc are changes to how external systems handle the variable (the editor and RPC system respectively), whereas @onready changes how the variable is initialized within GDScript itself. (Since changes to get_property_list() and duplicate() behavior are secondary effects, not the primary effect that these annotations are meant for, I would argue that these are not relevant to this argument)

[dalexeev]

See #828:

Describe the problem or limitation you are having in your project: Excessive keywords and complex syntax for some features (export, setget). Some keywords are allowed as identifiers to overcome this, but it ends up being a bit hacky.

Describe the feature / enhancement and how it helps to overcome the problem or limitation: Adding annotation syntax to GDScript to offload the amount of reserved words. With the potential possibility of including meta-data to scripts so first- and third-party tools can use them to provide extra features.

The main idea was to keep the number of keywords to a minimum. This is especially important for modifiers, as they are not used by themselves. Modifiers found in many programming languages (static and possibly public/private in the future) have remained keywords, while Godot-specific modifiers have been replaced with annotations.

I don't think the difference between a keyword and an annotation should be whether it has an effect on behavior or not.

See also:

• GDScript: Change static to an annotation #5165
• Add public/private access modifiers to GDScript and autocompletion improvements #641

[dalexeev]

We recently discussed the annotations vs keywords issue at a GDScript team meeting. While we have not been able to formalize a general rule about which option should be used for a new functionality, we have reached a consensus that existing keywords and annotations should not be affected. See:

• Improve description of annotations godot-docs#9188
• Engine development / Engine core and modules / Scripting development

The documentation for GDScript clearly states about the semantics of annotations (reference):

Annotations affect how the script is treated by external tools and usually don't change the behavior.

This confusing statement was also corrected in the user manual by the above PR. Annotation semantics are mentioned in the contributor documentation.

So I think all the questions raised here have been addressed. Thanks for your input!