GDScript: warns that a class variable is unused while it actually is

[Zylann]

Godot 3.1 alpha 1

I made a subclass in my script just to hold a few variables together, however all of them produce an "unused" warning. Of course they are not used within that subclass (because it has no functions), but I use them like "public" variables elsewhere in the enclosing script, so the warning is just adding false positive noise.

class Item:
    var base = null
    var length = 0

var _items = []

func _ready():
    var item = Item.new()
    item.base = get_node("X")
    item.length = 5
    _items.append(item)
    #...

[aaronfranke]

Does the unused error show up if you try to read from them as well?

[Zylann]

@aaronfranke yes, I read from them further down but I think the parser is unable to tell.

[vnen]

Well, this is not a bug, it's the same as #22206. It's in the same file but not in the same class (which is the purpose of the warning). I'll probably disable this by default because it doesn't make sense for classes used only as a data structure.

[Zylann]

Still happens in Godot 3.1 alpha3

I'll probably disable this by default because it doesn't make sense for classes used only as a data structure.

How would you recognize such classes?
The only way I see is classes that have no functions, though that's only de-facto rather than a certain thing. Also checking variables starting with _ first could be done though, since they are used to mean private and therefore would be easier to check for usage within their class and subclasses.

[vnen]

How would you recognize such classes?

I won't, I'll just disable the warning by default. If you think it's useful you can turn it on and disable only for some scripts.

[Zylann]

@vnen would it be possible to have it on just for variables beginning with _? Because due to the de facto standard of privateness, they can be checked for usage much more accurately.

[vnen]

It's possible but it might be confusing because for function arguments it's the opposite: starting with _ means it's not checked for usages.

[Zylann]

@vnen function arguments start with _? I never saw that Oo
Do you mean _ is ignored if function arguments start with that in the attempt to say explicitely they are ignored? If that's the case, that's confusing already, but not because of the warning (never used that convention tbh, or mayybe I'd put the _ at the end). It also doesn't prevent from checking member vars starting with _, because you can check if a variable of the same name is a function argument (in which case there is a confusing conflict already, as I said above xD).

[aaronfranke]

_process(delta) gives a warning about unused delta unless you use it.

_process(_delta) does not.

[Zylann]

@aaronfranke yeah, I realized that. What I mean is that we just shot ourselves in the foot choosing a convention which already steps over another and prevents going further xD (At least if we consider not doing it because it's confusing)

[OvermindDL1]

What I mean is that we just shot ourselves in the foot choosing a convention which already steps over another and prevents going further xD (At least if we consider not doing it because it's confusing)

Although following the rest of the industry means that variables or bindings started with and underscope means it is 'unused' after declaration, either used as an unused 'hole' in an argument list or used for documentation purposes as the unused return of some expression. Many languages even bake the convention into the compiler itself to do precisely what is proposed here (to both signify a purposefully unused argument or to silence an 'unused return from function/expression' warning/error).

In all of those languages that I can recall a function name/binding starting with an underscore is not held or checked to these conventions but is rather just a normal function name, used to traditionally signify a private function in one of them but not held to that otherwise.

[Zylann]

So no chance to check for member vars usage then?

[OvermindDL1]

So no chance to check for member vars usage then?

If they were private (if GDScript had a concept of private) sure, but in general I couldn't see how that would be possible.

[Zylann]

@OvermindDL1 get list of members, pick those starting with _, check functions and ignore occurrences that collide with arguments, unless prefixed with self? But to me the hard thing is not even the underscore, it's checking all classes inheriting it in the project to build a complete code model, depending if we are Ok walking all scripts or not.

[OvermindDL1]

@Zylann An issue with that though is that a class can have fields that are not used internally but only used externally, so you'd have to do a whole-program-analysis for it, and considering scripts can be dynamically loaded then that's impossible. I personally use many classes as C-like structs, pure data storage and no functionality.

[Zylann]

@OvermindDL1 this is the point of the underscore. Just like the convention in unused arguments (already in use), they are a convention the parser can use. In member vars, it can be used to indicate privateness, which means the parser could ignore the case of external access.
For the struct classes this issue was about initially, we can't do the same check obviously since they would not have that prefix.

[Calinou]

I'm getting an unused class variable warning with the following snippet on commit 6607c3c:

onready var preloader := $ResourcePreloader as ResourcePreloader
onready var bounce_sounds := [
	preloader.get_resource("bounce.0"),
	preloader.get_resource("bounce.1"),
	preloader.get_resource("bounce.2"),
	preloader.get_resource("bounce.3"),
]

Is this related since I'm using it just below in another member variable?

[aaronfranke]

What's the current status of this issue? Is there a plan to deal with it? Perhaps bump to 4.0?

@vnen: I won't, I'll just disable the warning by default.

The warning is still enabled in the current master. Should the warning be disabled by default?