Proposal: Access Modifiers for Classes in GDScript

Hoyv · March 13, 2025, 11:22am

Proposal: Access Modifiers for Classes in GDScript
Introduction
Currently, GDScript does not support access modifiers (private, protected, etc.), which are common in many programming languages like C#, Java, and Python (with _ and __ conventions). The lack of access control makes it difficult to encapsulate logic properly and prevent unintended access to internal data structures.

This proposal suggests adding access modifiers to GDScript to improve code safety, maintainability, and encapsulation.

Why is this important?
Encapsulation & Data Safety:

Without private or protected members, all classes expose their internals, which can lead to unintended modifications from outside the intended scope.
This increases the risk of bugs and accidental changes.
Better Code Organization & Readability
Explicit access modifiers improve readability by indicating which parts of the class are meant for internal use.
This is especially important in large projects with multiple developers.
Aligning with Object-Oriented Programming (OOP) Principles
Godot already supports OOP concepts like inheritance and polymorphism, but without access control, it’s harder to enforce encapsulation.
Consistency with C# in Godot
C# in Godot already supports private, protected, and public access modifiers. Adding similar functionality to GDScript would make it more consistent across the engine.

Proposed Solution
Introduce three levels of access control:
public (default) – Accessible from anywhere (same as current behavior).
protected – Accessible only within the class and its subclasses.
private – Accessible only within the same class.

Backward Compatibility & Implementation

The default behavior can remain public to ensure compatibility with existing scripts.
Access modifiers can be optional, allowing users to adopt them gradually.
A basic implementation could be enforced at the parser level to restrict access accordingly

Conclusion
Adding access modifiers to GDScript would significantly improve encapsulation, maintainability, and project scalability. It would also make GDScript more aligned with modern programming practices and Godot’s existing C# implementation.

This feature would be a valuable addition to Godot 4.3+, helping developers write safer and more maintainable code.

**

So, would you like to have access modifiers in GDScript?

**

dragonforge-dev · March 13, 2025, 2:55pm

Yes it does.

Well, it supports public and private access modifiers.

If you precede a variable of function name with an underscore (_), it is private and cannot be accessed outside of that script, except by inherited classes.

As far as I know, there’s no concept of protected in GDScript.

var _my_var: String = "I am a private variable."

func _my_function(member_var: int) -> void:
    return "I am a private function. I must be called within this script."

gertkeno · March 13, 2025, 3:56pm

Even with a preceeding underscore the variable and function can be used outside the script, just like in Python. There is however a warning if a underscored “private” variable is unused within the class body, as Godot seems to expect private variables to work but does not enforce them (as of 4.4).

Proposals can be submitted to this github issues page, though private/public access is already proposed.

github.com/godotengine/godot-proposals

Add public/private access modifiers to GDScript and autocompletion improvements

opened 09:43AM - 27 Mar 20 UTC

2plus2makes5

topic:gdscript

**Describe the project you are working on:** 2.5d beat'em up **Describe the …problem or limitation you are having in your project:** Inside a GDScript class i often use "private" variables and functions that shouldn't be visible ouside but that instead are "public", hence visible and usable by everyone. More or less related is the fact that autocompletion is cluttered, yes alphabetic order is good but the list always starts with lots of constants and the function or variable we want is usually buried in lots of other things that aren't useful in that moment. **Describe the feature / enhancement and how it helps to overcome the problem or limitation:** Let us specify if a variable or function is private or protected(or whatever keywords you want to use), a private variable can only be used by the functions of the same class, protected means that it's also accessible by the classes that inherit from the class the variable is in. About autocompletion in my opinion it would be even more useful if suggestions were grouped by class, ordered from the leaf of the class tree back to the root class, or maybe add to the editor's options the possibility to order and filter what is shown. **Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:** var v(no access modifier means public) protected var v(accessible only in the class it's in and the ones that inherit it) private var v(accessible only in the class it's in) Autocompletion suggestions would be grouped by class, ordered from the leaf to the root of the class tree, maybe with their class written somewhere. It would be also helpful if the suggestions were colored the same way as in the editor, this way it would be even faster and easier to find what we want. **If this enhancement will not be used often, can it be worked around with a few lines of script?:** Access modifiers and autocompletion are essential features so they would be used very often and probably they can't be made with few lines of script. **Is there a reason why this should be core and not an add-on in the asset library?:** It seems to me that a GDScript feature like these ones should be core.

dragonforge-dev · March 13, 2025, 7:32pm

Noted. Thanks for the info.