_unhandled_key_input's 'event' argument does not have InputEventKey as its type

[sealionnn]

Tested versions

4.3

System information

Window 11

Issue description

_unhandled_key_input's event has a type of InputEvent, but shouldn't it use InputEventKey? To get the correct auto-complete, you have to use a workaround like var _event: InputEventKey = event. Unless I am mistaken, event in this method should always be InputEventKey, so there is no reason to use the parent InputEvent instead. event's type cannot otherwise be overridden.

Steps to reproduce

Use _unhandled_key_input.

Minimal reproduction project (MRP)

N/A

[timothyqiu]

I think this is an API left over from the early days of Godot, when InputEventKey was a data member of the InputEvent class, not a subclass.

Unfortunately, changing the parameter type now would break compatibility more than it would be worth.

[sealionnn]

Thanks for your response. Godot 3 has the event typed correctly, so it stands to reason that this is an oversight in the current version and not an issue linked to an older version of Godot, unless I misunderstand you. My programming knowledge is mainly limited to working within game engines like Godot, but would it really be that complex to change the type of an argument for a single function in the source code?

[timothyqiu]

Godot 3 has the event typed correctly, so it stands to reason that this is an oversight in the current version and not an issue linked to an older version of Godot

Makes sense.

Did some research and it turns out to be the virtual method refactoring PR (#51983) that caused this change in 4.x.

• unhandled_key_input in engine code has always been using InputEvent.
• 3.x changes the parameter type to InputEventKey when binding the virtual method.
• 4.0 changed the way virtual methods are bind so it's automatically using the signature of the C++ method.

would it really be that complex to change the type of an argument for a single function in the source code?

Changing the type of a parameter is very easy. The problem is that doing so may break compatibility, i.e., break existing projects that relies on the fact that the parameter is InputEvent.

[and-rad]

I stumbled over this a couple times myself, so I'm in favor of eventually changing the type. I feel it's not too bad of a compatibility breakage to not do it in the 4.x cycle, but others might see that differently.