Godot-CPP: Support collections within gdnative structs

[tucono]

I apologize if I am butchering terminology in this post as I am largely self-taught and I am rather ignorant about C++ as a whole.

My current problem:
I've been working on a possible solution to provide all collisions during a raycast. However, I've hit a snag in that my solution passes an empty Vector<RayResult> into the raycast interception function and populates it within. This works fine in godot itself, however creating bindings to support this method in godot-cpp appears to have significant complications. A quick-and-dirty workaround was to wrap the vector within a struct - struct MultiRayResult { Vector<RayResult> collisions; }. However, registering this as a GDNative struct breaks the auto-generated files in godot-cpp.

Digging into the python binding_generator.py file of godot-cpp shows that it does not support any components that may indicate a collection of another type. It does this by simply grabbing the type name of the variable in full and using that to generate the file includes. This means that any struct containing a Vector, HashMap, or any other 'template'/'collection' type (typically of the form Collection<TypeName>) is directly generated to the include #include<collection<_type_name>.hpp> which obviously breaks godot-cpp compilation.

Is there a significant reason that this isn't supported within godot-cpp? It seems a bit of a strange limitation to me considering many different object collections are used throughout the engine. The apparent workaround as of now is to instead pass the starting memory position of the collection as a pointer, provide a maximum limit to the number of components in the collection (as otherwise you may attempt to access invalid memory) which creates a false limitation of the number of objects that can be added to the collection and requires more work by a user to ensure they've properly allocated memory space before calling the function. It just seems strange to me to require this when many collection types explicitly allow dynamic resizing (e.g. Vector).

As of now I have a naive workaround that extracts typenames from within a <> pair here but I very much don't trust its robustness.