Add Variant::get_type_by_name

[Naros]

Fixes godotengine/godot-proposals#13633

Engine PR godotengine/godot#117160

@dsnopek, I realize you may want to handle the Extension API and GDExtension JSON files in a separate PR, but I've briefly added them here for testing, given that they're a bit intertwined.

[dsnopek]

Oh, I forgot that you already made a PR for this!

I just posted a new one: #1975

There's some small differences between them: in mine the Variant::get_type_by_name() function is only added if you're targeting 4.7, rather than returning VARIANT_MAX. We'll need to hash out which way we want to go

Otherwise, do you want to update your PR? Or, should we shift over to mine?

[Naros]

Hi, I don't care which PR we go with, that's entirely up to you.

But in terms of the return value, I opted for VARIANT_MAX as a non-4.7 return value so that for users who import and use variant.hpp from godot-cpp can just do this:

Variant::Type type = Variant::get_type_name(variantTypeName);
if (type == Variant::VARIANT_MAX) {
  // Handle error case
}

Given that the engine can return VARIANT_MAX when the provided input is wrong, it keeps the error-handling logic for the client call agnostic to version semantics. To me this fits well with the design of godot-cpp supporting versions back to Godot 4.4 seamlessly. Without it, now users need to do:

#if GODOT_VERSION >= 0x040700
Variant::Type type = Variant::get_type_name(variantTypeName);
if (type == Variant::VARIANT_MAX) {
  // Handle error case
}
#else 
// Handle unsupported case
#endif

I just find the former approach cleaner and leaves the version semantics of what is/isn't supported as an encapsulated concern in this case, since it's obvious from godot-cpp that we cannot call the engine method pre-4.7. But perhaps I am missing something?

[dsnopek]

I wouldn't expect users of godot-cpp to use an #ifdef for this. I'd expect an extension to have a fixed target API: they either target Godot 4.7+ or they don't. If they target Godot 4.7+ they can use that function, and if they don't, then they can't (until some later point where they increase their target API).

Does your extension support multiple target APIs? Since that's only possible with godot-cpp v10, there won't be a lot of examples in the wild for a while

[Naros]

Does your extension support multiple target APIs?

We do, but it's compile-time targets, obviously.

Our main branch and previously supported branches often differ only in the godot-cpp they target. So the code is littered with #if / #elif / #else blocks based on version differences, often hidden by a function facade that works regardless of the underlying godot-cpp version.

So I was applying that same reasoning here: if we check out godot-cpp v10 and then say we want to compile with 4.6+ compatibility, the variant.hpp would have get_type_name but would always return VARIANT_MAX. If I compiled using v10 but with v4.7+ compatibility, that same method would return the engine's value.

This would allow us, for example, to have our plugin's A.B, B.C, and C.D branches all use godot-cpp v10 but compile against different extension-api versions. So the only preprocessor wrappers we'd need to concern ourselves with would be around exposed differences in the Scripting API and not necessarily godot-cpp.

But that may just be an ideal world that's not practical, idk.

[dsnopek]

Superseded by #1975

Same as I said there, we can keep discussing a possible fallback in a follow-up (either as VARIANT_MAX or a fixed mapping)