Return an object instead of a dictionary for the function intersect_ray()

[jakedruth]

When using the function PhysicsDirectSpaceState2D.intersect_ray(), the return result is a dictionary. The dictionary makes it very difficult to understand the result while in the editor unless you have access to the documentation. Without that prior knowledge or access, it is impossible to know what strings you need to use to get the information. Additionally, typing a string is prone to typos, allowing code to compile but not work as intended. Also, in C#, you need to cast each element to its corresponding type, adding another layer of obfuscation to the process.

I propose the function instead returns an object named something like RaycastHit or RaycastInfo, which has the same Properties as the returned dictionary (position, normal, collider, collider_id, rid, shape, metadata). This way, IntelliSense would also work, speeding up production and eliminating the guessing game of how to access the variables.

intersect_ray() Documentation

I did find the following issues, but no discussions yet talking about this.
#4474
#7661

I guess one question, to start a discussion, is why does Godot return a dictionary instead of a class/ object?

[Mickeon]

I guess one question, to start a discussion, is why does Godot return a dictionary instead of a class/ object?

Because in comparison, creating a whole new Object is comparatively slower than returning a Dictionary.
Other languages would use structs (and so does the engine internally) because they're much, much more efficient. But, Godot has no such concept exposed on the user. A Dictionary is as close as it can get right now.

Fun fact, this very exact intersect_ray was the catalyst for the following PR being developed: godotengine/godot#82198

[jakedruth]

2 follow-up questions,

1. Is there any way to test/ show that it is slower to return an object than a dictionary in the Godot environment? I don't fully understand Godot's architecture yet and would not even know where to begin testing that.

2. Is returning an Object AND accessing its members slower than returning a dictionary AND accessing a key-value pair with a STRING and converting the value to the proper type (Vector2/3, Object, ObjectID, RID, int, and/ or a Variant()) multiple times if you need more than one item from the dictionary?
   The question about speed is not about what is quicker to return, it should be about what is quicker to access and use. If creating and returning an object is only a few CPU cycles slower than a dictionary, that time is irrelevant if it takes more CPU cycles to even access the information that is needed.

[jakedruth]

In c# accessing a dictionary with a "string key" can have an impact on the performance. I'm not sure if GDscript has the same issues or if it has a way of speeding up the process. Looking online, I can't find much information on that side of performance. I did see that Python's "dict implementation is in fact optimized for string key lookups" but I don't know if GDscript shares that as well.

[Enderlook]

For the C# API, it could return a struct which internally wraps the existing dictionary.
That would allow users to have a convenient API, and then in the future, the internal content of the struct could be replaced to avoid entirely the allocation of the dictionary.