Warn when defining a function that has the same name as a virtual method, but without a leading underscore (e.g. func ready():)

[Calinou]

Related to #3285, #3284 and #3159.

Describe the project you are working on

The Godot editor 🙂

Describe the problem or limitation you are having in your project

Defining a method that has a name similar to a virtual method (but lacking a leading underscore) will not cause any warning to be printed. However, the user is typically expecting the virtual method to be overridden. This can occur either due to a typo, or due to the documentation being skimmed over too fast (we've all been there).

This can cause confusion as seen in godotengine/godot#55024.

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

For example, the following code would emit a warning:

extends Node

func ready(): # Warning emitted here.
	print("Hello world!")

Function "ready" matches the name of a built-in virtual method, but without a leading underscore. It will not be called automatically. Did you mean to declare a function called "_ready" instead?

Ideally, warning-ignore annotations should be usable to prevent warnings from being emitted:

extends Node

# The warning name is a placeholder, feel free to suggest a better one.
@warning_ignore("virtual_method_lookalike")
func ready():
	print("Hello world!")

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

There are several ways to implement this:

• Add virtual methods that lack an underscore, only for the purpose of printing warning messages. This is tedious, can't be ignored using annotations and can potentially miss many cases. The upside is that this will also benefit non-GDScript languages such as C#, but it may not be as useful there.
• Implement this in the GDScript parser. This could be used to catch all built-in virtuals automatically.

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

No, as this is mainly about improving the new user experience.

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

See above.

[xsellier]

Hey,

Nice suggestion!
Regarding the annotation I have another suggestion which would be better for everybody I think:

extends Node

# So this function is gonna get called even if `ready` exists in Godot.
@override
func ready():
	print("Hello world!")

[Calinou]

@xsellier Adding an @override annotation is being discussed in #1631.

[xsellier]

@xsellier Adding an @override annotation is being discussed in #1631.

I think it is better to have @override than anything else. For a long time Godot was working like that. I mean, you can override a function in Godot 2 and Godot 3 (any versions but Godot 4). Now, let's say you are releasing Godot 4 as a Beta version. How many people will port their project to Godot 4 and expect GDScript to work as usual? I have no idea, but more than one I'm pretty sure.

I think it will be tiresome to explain to all those people that GDScript has changed and they cant do it anymore because that the way it works now. Sure we can discuss if we want @override or @ignore_warning but in the end if you don't pick @override or something like that you're going to get a lot of ticket like those:
godotengine/godot#55024
godotengine/godot#53606

Also, why would we want @warning_ignore("virtual_method_lookalike") if the function is never called in the end?
We'd better close this ticket in favor of #1631