Ideally, the FFI would only load methods which are in use, and panic if the hash of the used APIs change.
However, currently, Godot rust is loading all functions exported by the Godot API upfront, including deprecated and experimental methods (which by nature are subject to change).
In a particular example, Godot 4.2 has a few changes pending which could change method hashes on rarely used APIs. Sure, it would be better if they didn't, but it could conceivably happen.
And more worryingly, we might have future changes planned which may change some APIs marked as experimental (which in general should not be used if you want forward compatibility).
However, because ClassSceneMethodTable::load loads all methods defined in the JSON, used or not, it guarantees that any slight change in the Godot API even to a rarely-used, experimental or deprecated function, will break every godot-rust extension.
A good start on improving this might be to put experimental or deprecated APIs behind a flag, so at least those are not exported except for extensions that need them.
Beyond that, perhaps if there is some way to memoize APIs used (similar to how a C++ function-level static member is initialized exactly once on first call).
I'm not sure exactly, but I'm just filing this because it does seem like it could be a continuing point of frustration for deploying Godot rust plugins into the long term.
I know Godot 4.0 and Godot 4.1 had explicit GDExtension compatibility breakage because GDExt was new. But it is not intended to break the whole API globally, and ideally almost all APIs will remain compatible where possible.
I'm not really a contributor on the Godot GDExtension team, but I just ran into this and I am responsible for some of the APIs that might be subject to change, which are breaking all of my rust plugins, so I want to flag this issue and start the discussion on how to improve this situation, be it on Godot's side or Godot-rust's side.
Ideally, the FFI would only load methods which are in use, and panic if the hash of the used APIs change.
However, currently, Godot rust is loading all functions exported by the Godot API upfront, including deprecated and experimental methods (which by nature are subject to change).
In a particular example, Godot 4.2 has a few changes pending which could change method hashes on rarely used APIs. Sure, it would be better if they didn't, but it could conceivably happen. And more worryingly, we might have future changes planned which may change some APIs marked as experimental (which in general should not be used if you want forward compatibility).
However, because
ClassSceneMethodTable::load
loads all methods defined in the JSON, used or not, it guarantees that any slight change in the Godot API even to a rarely-used, experimental or deprecated function, will break every godot-rust extension.A good start on improving this might be to put experimental or deprecated APIs behind a flag, so at least those are not exported except for extensions that need them. Beyond that, perhaps if there is some way to memoize APIs used (similar to how a C++ function-level static member is initialized exactly once on first call).
I'm not sure exactly, but I'm just filing this because it does seem like it could be a continuing point of frustration for deploying Godot rust plugins into the long term.
I know Godot 4.0 and Godot 4.1 had explicit GDExtension compatibility breakage because GDExt was new. But it is not intended to break the whole API globally, and ideally almost all APIs will remain compatible where possible.
I'm not really a contributor on the Godot GDExtension team, but I just ran into this and I am responsible for some of the APIs that might be subject to change, which are breaking all of my rust plugins, so I want to flag this issue and start the discussion on how to improve this situation, be it on Godot's side or Godot-rust's side.