Mono: Improve engine methods object parameters (and use/allow structs?)

[Flavelius]

Describe the project you are working on:
Just looking forward to using godot

Describe the problem or limitation you are having in your project:
Currently some engine methods take object parameters that inherit huge godot classes, that in some cases don't even make sense or are unusable in that inheritance chain, for example
PhysicsShapeQueryParameters, which inherits from Reference. This allows it to be assigned a script or to receive notifications, have metadata etc. which is of no real use.
Or RID which is so lightweight it should probably be a struct.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
The obstacle is probably that currently System.object or structs seem to be unmarshallable for the most part as far as i understand it. But having that work could allow those bloated or uneccessarily allocating arguments to be more lightweight and developer friendly (easier to use, better performing/less allocating).

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
This proposal is halfway an issue report, so i'm unable to provide a solution apart from whats written in the feature description.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
No, it's part of the engine.

Is there a reason why this should be core and not an add-on in the asset library?:
It must be adjusted in the engine

[Flavelius]

Also, return values could be improved too. Most just return blackboxed dictionaries or arrays. It would be of great help for a typed language like c# to have those return maybe generic dictionaries or arrays of specific objects. The current situation involves a lot of casting and guessing and internet research what's inside such a returned dict/array.

[Calinou]

It would be of great help for a typed language like c# to have those return maybe generic dictionaries or arrays of specific objects. The current situation involves a lot of casting and guessing and internet research what's inside such a returned dict/array.

I think this will be possible in Godot 4.0, as typed arrays will be supported in GDScript and the scripting API in general.

[neikeq]

There isn't much we can do about this from the C# side. This is a scripting system limitation. It only allows built-in value types or Godot Object derived types, hence the use of bloated classes for things that could go in a simple struct.

[Flavelius]

Then it would be a step in the right direction if the underlying scripting system had more builtin structs for all of those usecases really where it makes sense (especially most methods that just return dictionaries with string indices), like in comparable game engines, as that will make usage for beginners (and advanced users alike) less error prone, and probably even give a slight performance boost i can imagine.
Supporting custom structs is probably another problem, that could(/should) be tackled in the future.