GDScript 2.0: Static typing on signals isn't enforced

[AaronRecord]

Godot version

v4.0.dev.custom_build [a851012b1]

System information

Windows 10

Issue description

The following code:

signal test(a: Node2D, b: Camera3D)

func _ready():
	test.connect(func(a, b): print(a + b))
	test.emit(Vector2.UP, Vector2.RIGHT)

compiles without any errors, and prints (1, -1).

---

It should produce an error, something like:

Invalid argument for "emit()" function: argument 1 should be Node2D but is Vector2.
Invalid argument for "emit()" function: argument 2 should be Camera3D but is Vector2.

Steps to reproduce

See above.

Minimal reproduction project

No response

[akien-mga]

Duplicate of godotengine/godot-proposals#2557.

[AaronRecord]

Duplicate of godotengine/godot-proposals#2557.

I was aware of that issue, the weird part is that is accepts type arguments without complaint, it just doesn't use them. On 3.x you get an error if you try to add types to signal arguments. So if this won't be supported for 4.0 then the ability to add types to signal arguments should be removed.

[Calinou]

See also #52083 (comment).

[dalexeev]

See also godotengine/godot-proposals#2557 (comment).

[AaronRecord]

See also godotengine/godot-proposals#2557 (comment).

Okay, but at the very least this limitation should be documented before this issue is closed, otherwise it's quite counterintuitive as many users will expect the types to be enforced.

[adamscott]

@vnen I would push this issue to 4.x or 4.1

[qaptoR]

Bumping this as relatively important for the following reason:

When checking the types for the argument list of a signal against those of the parameter list for a potential method that will connect.

In this instance, for every built-in signal there are types, for custom signals the types are all '0'.
This is inconsistent behaviour as custom signals should have the same functionality as built in signals.

[dalexeev]

This is inconsistent behaviour as custom signals should have the same functionality as built in signals.

There is no protection for built-in signals either, you can emit a signal with any arguments. The only "protection" is callback type hints. The difference from built-in signals is that the editor does not currently use this information when generating a custom signal callback. But this can be considered a bug that we need to fix.

extends Node

func _ready() -> void:
    child_entered_tree.connect(_on_child_entered_tree)
    child_entered_tree.emit(42, [], NAN) # No error.

#func _on_child_entered_tree(node: Node) -> void:
#    pass

func _on_child_entered_tree(a, b, c) -> void:
    prints(a, b, c)

[vnen]

In this instance, for every built-in signal there are types, for custom signals the types are all '0'.
This is inconsistent behaviour as custom signals should have the same functionality as built in signals.

BTW this isn't related to enforcing types on signals, this is only because script info is not being populated properly for all the get_*() functions. It's the same problem as #67544

[FabriceCastel]

Wanted to chime in with an example as to why this feature is important. I had the following code:

# event_bus.gd
signal on_update_letters(word: String, letters: Array[bool])

# level.gd
func _ready():
	var word = "ICY"
	var letters = [false, false, false]
	EventBus.on_update_letters.emit(word, letters)

# level_ui.gd
func _ready():
	EventBus.connect("on_update_letters", on_update_letters)

func on_update_letters(word: String, letters: Array[bool]):
	print("This should get printed, but it never gets invoked")

Can you spot the bug?

on_update_letters in level_ui.gd never gets called because letters in level.gd is NOT an Array[bool]. Don't know why, honestly, but changing that line to var letters: Array[bool] = [false, false, false] resolves the issue.

It's way too easy for minor type mistakes to lead to silent failures, and they're extremely annoying to debug. I haven't had to do any refactoring work around signals yet, but I'd bet my bottom dollar that it can be a similarly frustrating debugging experience.

Calling emit on a signal with params that do not match the types in its declaration shouldn't fail silently.

[vnen]

So, this is not really a bug. It could be changed but it is like so by design because the core never enforced types either. The types you can set are only for documentation purposes, at least for now, the same as they are in core.

[dalexeev]

The difference from built-in signals is that the editor does not currently use this information when generating a custom signal callback. But this can be considered a bug that we need to fix.

Fixed in #79366 and others.

• See also Add type hints for signal parameters godot-proposals#2557.