An onready variable without initializer could be a warning

[theraot]

In a line like this:

@onready var button_container:Container

The @onready annotation has no meaning since the variable has no initialization. It could be that we forgot to write one.

[geekley]

I don't really like this as proposed. It could be on purpose too.
Adding @onready to an uninitialized field can be useful to mark that you're initializing it inside _ready(), to visually distinguish it from other fields, but mentally group it with other @onready initialized fields.

To me, making this stricter would be useful only if we got a warning/error only if such variables aren't assigned to, neither inside _ready() nor inline. Then its semantics could be:

@onready var node1: Node = $Node1 # initialized by start of _ready
@onready var node2: Node # must be initialized by the end of _ready; perhaps also before any await instruction
func _ready() -> void:
  if debug:
    # complex logic...
    node2 = $Node2_Debug
  else: node2 = $Node2
  # would be error if node2 were not definitely assigned by the end of _ready

Since we're explicitly saying it's initialized @onready, it doesn't need to check other methods, etc. for indirect initialization IMO.

[theraot]

As posted, it is a discussion, not a proposal.

I have no reason to believe it is intentional, but that is for the Godot team to settle.

Now, what you suggest might work.

• I see one drawback: it would make checking complex. For example, what if there are await in _ready, what if I connect a method to the ready signal, what if I set the variable using set...
• And I would make one addendum: it should also be added to the GDScript style guide.

Meanwhile, you have other ways to make a gestalt of related fields, including comments, spacing, and regions.

As per the warning being too strict, I want to say that I like strict, but if you don't, Godot lets you disable any warnings via project settings. So that shouldn't be a problem.

[geekley]

I see one drawback: it would make checking complex. For example, what if there are await in _ready, what if I connect a method to the ready signal, what if I set the variable using set...

This is why I suggested it doesn't need to check for any sort of indirect assignments, signals, etc; it's enforced just inside the method itself. As for await, the checks are enforced only for the code that runs synchronously/immediately when the _ready function is called. As for setters, you can check it only from the outer visible property perspective, without caring about any underlying field implementation.