Fletcher Porter

> They can also change independent of the engine version I don't think this matters per se; if you're already using `custom-godot`, you're going to take whatever Godot version you...

But now an additional idea: could this be done without `custom-godot`, perhaps by interfacing with the gdextension binary directly?

There's also an option for build-time reflection by creating a headless Godot app that that writes the API of an extension named from an arg or stdin to stdout.

What about doing it as a trait? The macro-based APIs could also be provided, but a trait-based API could be a little nicer for more complex applications. Here's a back-of-the-napkin...

> * Even once it does, it will only do so for newer Godot versions (>= 4.4 at least), meaning people supporting older versions won't have nullability information. I wonder...

In cases where the godot versions between gdext and godot bin are incompatible, it'd be good to read out the version numbers explicitly (for example, if you select the wrong...

When changing the base class of an object and hot reloading, gdext spews a bunch of errors, but the first one that godot itself provides is all that's required for...

What if exporting trait impls were done really naively, like just export the methods in the trait impl the same as for those in the struct impl. But then also...

> This would allow other applications to embed Godot, but I don't think it would allow Godot to embed Godot. Genuine question, what's the difference?