Add `@private` for GDScript

Lazy-Rabbit-2001 commented 3 weeks ago

Parallel to

Describe the project you are working on

Godot GDScript Improvements

Describe the problem or limitation you are having in your project

There has been a related pr about adding soft access restriction by adding _ prefix. However, the prefix conflicts with the use of pure virtual methods (empty virutal methods, usually called by the engine or other codes).

Having taken the chat in this pr as a reference, modifiers are discussed to be annotations. As there are still another half of Godot users who do not prefer prefixing with _ for warnings, annotations would be a solution.

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

Introducing @private to replace the _ prefix, which also avoids conflict with pure virtual methods
During completion, hide private members if the members are not allowed to be accessed.
Updating the online documentation (GDScript style guide) about private and public members

Still, all members are by default public to all scripts, and all unexpected access will be regarded as warnings instead of errors to maintain the compatibility at the most extent, which keeps the same base line as this pr.

Note: In GDScript, @private = protected in other languages.

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

class A:
    @private static var private_member = 1 # Note: Goes the same for non-static members

class B:
    func _init():
        A.private_member = 2 # Push a warning
        print(A.private_member) # Push a warning

Note: You can turn this into an error manually, but it is not recommended to ignore the warning or the error.

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

No.

Why propose this PR?

There has been a pr already, but since someone mentioned the annotation, I want to re-pick this up and make this a discussional proposal for the pr. Your thoughts will eventually change the way I implement the pr.

AThousandShips commented 3 weeks ago

See also:

Not sure why this needs a dedicate proposal

Lazy-Rabbit-2001 commented 3 weeks ago

Discussion is also okay but i think a proposal may attract more focus on this topic.

AThousandShips commented 3 weeks ago

What discussions? These are proposals covering the same thing?

dalexeev commented 3 weeks ago

As far as I can tell, in the last discussion among GDScript contributors, we reached a consensus that we would not like to introduce explicit access modifiers (whether keywords or annotations) if their effect is limited to static analysis only. Either the access modifiers should have runtime guarantees for untyped code (which has performance implications and is hard to implement), or it should be a warning based on existing naming conventions, without any keywords/annotations.

There are already two proposals about access modifiers, creating a third one with a minimal difference (annotations instead of keywords) does not seem like the right way to draw attention to the topic.

godotengine / godot-proposals