Make onready variables created from dropping nodes include custom types

[theraot]

Describe the project you are working on

3D platformer with some cross-genre mechanics

Describe the problem or limitation you are having in your project

When I drag a Node into the script editor while holding Ctrl, I get something like this:

@onready var button:Button = %Button

But even if the Node has a script attached with a class_name I still get the same. Which is a problem because it means I don't get auto-completion for the members of my script.

Furthermore, apparently it is not type safe (notice the pale line number):

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

I want Godot to look if the dragged Node has a script and if that script is in the global lists of class and use that to generate - if possible - code like this:

@onready var button := %Button as CustomButton

That way I get auto-completion for the members defined in my custom class.

Also notice the line number is not pale:

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

We try to get the reference to the script attached to Node being dragged, and it is not null, we try to look into get_global_class_list to see if it is there, and if it is, use the class name from there in the generated code.

And also change the format of the generated code to match the example shown above.

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

It cannot be done via scripting. Plus, I believe this will be used often.

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

Again, it is not possible to accomplish via scripting. Creating onready variables when dropping nodes into script editor and holding Ctrl is a core feature.

[dalexeev]

Furthermore, apparently it is not type safe (notice the pale line number)

Yes, the green lines indicate the type safety of the code. But they do not mean that the code is better or more reliable.

Note from the PR discussion: The problem with this option is that it hides an error if the node in the scene is of the wrong type (for example, the user changed the type of the node in the scene but forgot to update the type hint in the script). The as operator will silently cast an object to null without any error. What can confuse the user: the node exists in the scene, the path is correct, @onready is used, but for some reason the variable is null.

[Deozaan]

But they do not mean that the code is better or more reliable.

But it is better because it has auto complete for class functions and properties.

[dalexeev]

@Deozaan If you're using a static type, there will be autocompletion too. I compared options 1 and 2, not 2 or 3 and 4.

@onready var option_1: Type = $Node
@onready var option_2 := $Node as Type
@onready var option_3 = $Node as Type
@onready var option_4 = $Node

[theraot]

@dalexeev

I've seen plenty of people say they don't get autocompletion, and I have struggled with it myself. I have now realized we have been conveying the problem wrong.

It is not that we don't get autocompletion. We get autocompletion.

It is that we don't get the members of the custom type in autocompletion.

[dalexeev]

@theraot Yes, there are bugs with autocompletion, but I don't think it changes what I wrote above. Even if in some cases the as operator allows you to workaround a bug, this is not the main purpose of the operator. In this case, the as option hides an error (and also adds extra runtime code, but this is less important).

If you notice an unreported bug with autocompletion, please open an issue. This proposal is closed and is not intended to discuss bugs. Thanks!