Update private member style in GDScript style guide.

[Jack-023]

This proposal is a non-functional change, just a suggestion on the style guide. Sorry if this is not the right channel for these types of proposals.

The styleguide suggests prepending a single _ to the name of "to virtual methods functions the user must override, private functions, and private variables". This makes it difficult to add a linter rule for warning against private member access as the same syntax is used for functions that are intended to be overridden. I suggest updating the style for private members to __ (double underscore) to avoid this issue. The convention of using underscores is pretty common in other languages but given that it is a non-functional change it would be much easier to update.

[AThousandShips]

Double underscore to me hurts readability, it's hard to tell at a glance, it is also used in at least some other language standards as prefixes for reserved things, which might complicate things

While changing the style guide is a non-functional change I'd also say it still affects existing guides, official demos, any work on linters existing or planned (including official ones), so it should be done with care IMO, especially if people expect others to follow a particular version of the style guide

Edit: Also one engine feature would have to be changed, namely the names of signal receivers, so they should be adjusted to this and be __Button_on_pressed for example

I think it's an interesting idea though

[Jack-023]

Double underscore was just the first thing that came to mind as and example, I'd be happy for it to be something else as long as it is distinct.

I was thinking that it would be simpler to change because you wouldn't be forced to update existing projects. Worst case scenario you get some new warnings when you linter updates but they were likely not working for this anyway.

I didn't think of signal receivers though, that does make it much more complicated to address this.

[dalexeev]

In my opinion, we could drop the "use underscores for virtual methods" recommendation. There is no point in using underscores for public methods. Native virtual methods like _ready() are not meant to be called from outside. Also usually there is a pair public final method + private virtual method, like get() and _get(). So, native virtual methods can be considered private/protected (some languages like Haxe ​​don't have a private/protected distinction).

As for abstract/virtual/final/must-override methods, I think we could use keywords/annotations instead. The base class is always known statically, so we won't have problems with the dynamic nature of GDScript, unlike access modifiers.

class A:
    func f1(): pass
    @virtual func f2(): pass
    @virtual func f3(): pass
    # No func f4().
    # No func f5().

class B extends A:
    func f1(): pass # Warning: Overriding a non-virtual method.
    func f2(): pass # Warning: Overriding a method without @override.
    @override func f3(): pass # OK.
    @override func f4(): pass # Error: Overriding a non-existent method.
    func f5(): pass # OK.

[dalexeev]

I find removing the underscore for virtual methods makes them a lot harder to spot at a glance.

I mean only public virtual methods. In my opinion, something._get_x() looks weird, public virtual methods should not start with an underscore. Private virtual methods will still use underscores (because they are private, not because they are virtual).

func public_final(): pass
@virtual func public_virtual(): pass
func _private_final(): pass
@virtual func _private_virtual(): pass

t's also less consistent with Godot's core APIs, which is a bad thing for editor plugins as it makes them feel less "integrated" with the rest of the engine.

As I said above, all or most native virtual methods are not intended to be accessed from outside, they are private/protected.

[Jack-023]

I like this suggestion much more than what I was originally proposing. You make a good point about the virtual methods in the engine's types generally being private.

[timothyqiu]

In my opinion, something._get_x() looks weird

I think we're currently mixing up the different meanings of "virtual". It is not equivalent to virtual in C++, because methods defined in GDScript are always virtual by definition in C++: they can be overridden by methods in derived classes.

Methods like _ready and _process are callbacks that does not exist if not defined, thus virtual. They should not be called manually in the first place.

[dalexeev]

By "virtual" I mean the same as in C++. Yes, in GDScript technically all methods are virtual, however it is not good style, usually you have relatively few methods that you really think can/must be overridden. We could go the other way and introduce the final keyword/annotation, but then you would have to use it with almost every method if you don't want virtual by default.

[Jack-023]

Nothing is really private in GDScript either. In both cases the style is being used to convey developer intent where the language lacks the features to describe it through syntax.

[timothyqiu]

GDScript borrowed the term "virtual" from C++, but for a different usage. The virtual qualifier is also not well-documented. I think that's the cause of the confusion.

All methods are virtual^C++ in GDScript. The virtual qualifier in GDScript specifically means "it's an engine callback" rather than the broader meaning of "to be overriden".

The current style guide makes sense: Leaving aside the fact that there is an overlap between the concepts of virtual^GDScript methods and private methods, neither should be called manually from outside.

So the _ prefix only implies private (i.e., don't call from outside). The only way to determine if a method is virtual^GDScript is to check the class reference for the qualifier virtual.

You can generate the class reference XML with the --doctool <path/to/output/dir> command line option.

[Jack-023]

The virtual qualifier in GDScript specifically means "it's an engine callback"

This is pretty confusing language to use if that is actually the case. I don't think that the GDScript style guide, a document for GDScript users, should be relying on some knowledge of the c++ implementation. If it is specifically referring to engine callbacks, it should probably just call them that to be unambiguous.

[timothyqiu]

This does not require an understanding of how virtual methods are implemented in C++. Virtual methods and callbacks are programming concepts, not language-specific concepts.

The problem here is that “virtual methods” in GDScript are not exactly what is commonly understood, which leads to confusion. (i.e., engine callback vs dynamic dispatch).

[Jack-023]

What I was trying to say is, when you say:

All methods are virtual^C++ in GDScript.

That sounds like an implementation detail. It is not obvious at all from a GDScript user's perspective. It is likely that GDScript users will assume (as I have) that it is talking about methods that are intended to be overridden (even if that isn't actually enforced by the language, like how privates aren't actually private).

[azur-wolve]

possible future annotations

@abstract func foo()

@virtual func foo(): pass

@override func foo(): #code

@private func foo(): pass