GDExtension: Showing How to Automate Binding with Metaprogramming. Improve Compile Time Validation, Type Safety.

[ghost]

I've always been a little annoyed at the binding interface.
-"Gotta add in some glue code to export this variable real quick" ...
-"And add to a param to this signal. Update the callback here... and here... and here..." ...
-"And here. Recompile" ...
-"Oof, spelled the name wrong there. Recompile" ...
-"Oof again, I used godot::Variant::INT but I should have used godot::Variant::FLOAT. Recompile again." ...

I can tell from the method and variable signatures how everything should be binded to the engine, so why do I have to write code to do it? I'm pretty good with metaprogramming in C++ so that's what I did and a few coffee filled weekends, here I am.

I only recently got this iteration compiling. It needs testing, but it is still good as a proof of concept. I think it is a pretty sleek interface so I figured I would probe for interest from the maintainers of GDExtension.

Updated:
https://github.com/TacticalShovel-Github/BiBS-Auto-Binder-for-Godot

[dsnopek]

One of the design goals of godot-cpp is to provide (as much as possible) the same API as used internally by Godot module in the engine itself.

So, in order to provide an API like this:

1. It could be added to Godot itself, which would allow godot-cpp to also use it.
2. A new C++ binding could be created that doesn't aim to be compatible with engine code like godot-cpp.
3. This could be provided as a separate library that could be used on top of godot-cpp. (I don't actually know if this is possible - you may be depending on changing GDCLASS() or Wrapped in order to make this work)

[ghost]

What it is doing is using templates to generate the binding code against existing interfaces (ClassDB::bind_method, ClassDB::add_signal, etc).

From what I've seen, the engine objects use the same binding functions so it isn't necessarily clear to me why both godot-cpp and the engine wouldn't both be able to use this interface.

I'm not actually changing anything in the engine. There's an obscure trick with partial specialization and {concepts/SFINAE} which you can use to enumerate declarations of the same type. That lets you do things like unroll for-loops on top of compile-time metadata.

[dsnopek]

Sounds very cool!

so it isn't necessarily clear to me why both godot-cpp and the engine wouldn't both be able to use this interface

I'm not trying to say they wouldn't be able to, I was trying to make a point about process. I'm on the GDExtension team and help maintain godot-cpp: we wouldn't add this API to godot-cpp, unless it was added to Godot itself first. So, if the goal is to get it into godot-cpp, the first step would be to convince the core team that this should be added to the engine. However, if that's not the goal (or the core team doesn't want to add this to engine), then there's options nr 2 and 3 that I gave above.

[ghost]

Understood.

I just want feedback along the lines of...

1. "Wow, this is amazing. We want it exactly like it is written here."
2. "We like the idea in principle, but we want it to look like this, and it needs to do this"
3. "Probably not the whole thing, but this part is nice." (psst. Exports)
4. "They can always be improved, but we are happy with the current set of interfaces."

Of course, since this is all in my private code base, I could publish it in my own repo as a header only solution without coupling into godot. I might do that if there is some interest in principle, but otherwise I would rather move onto other projects.

[ghost]

I lied and didn't move onto other project.
I've got the important parts functioning.

It does a lot of interesting tricks to get the syntax to work without code-gen.
Check it out if you think these kinds of C++ tricks are interesting.

https://github.com/TacticalShovel-Github/BiBS-Auto-Binder-for-Godot