Bug when using the String module operator for Variant type.

[YooRarely]

Tested versions

• 4.3.stable

System information

Windows 11

Issue description

I found that the module_Variant method for the String type in GDExtension did not return the correct result. They all returned an incorrect result <null>. Could this be a bug? I haven't found any posts mentioning a similar issue.

Steps to reproduce

I tried the following code. The output on the left is correct, while the result on the right is incorrect.

        Variant iv = (int64_t) 10;
        Variant dv = 99.9;
        Variant bv = true;
        GD::print(iv," ",String("%s") % (int64_t)10, "  ", String("%s") % iv);
        GD::print(dv," ",String("%s") % 99.9, "  ", String("%s") % dv);
        GD::print(bv," ",String("%s") % true, "  ", String("%s") % bv);

10 10  <null>
99.9 99.9  <null>
true true  <null>

They each used different overloaded operators, as shown below.

// [incorrect]
String operator%(const Variant &p_other) const;
// [correct]
String operator%(bool p_other) const;
String operator%(int64_t p_other) const;
String operator%(double p_other) const;

source_code

String String::operator%(const Variant &p_other) const {
    return internal::_call_builtin_operator_ptr<String>(_method_bindings.operator_module_Variant, (GDExtensionConstTypePtr)&opaque, (GDExtensionConstTypePtr)&p_other);
}
String String::operator%(bool p_other) const {
    int8_t p_other_encoded;
    PtrToArg<bool>::encode(p_other, &p_other_encoded);
    return internal::_call_builtin_operator_ptr<String>(_method_bindings.operator_module_bool, (GDExtensionConstTypePtr)&opaque, (GDExtensionConstTypePtr)&p_other_encoded);
}

String String::operator%(int64_t p_other) const {
    int64_t p_other_encoded;
    PtrToArg<int64_t>::encode(p_other, &p_other_encoded);
    return internal::_call_builtin_operator_ptr<String>(_method_bindings.operator_module_int, (GDExtensionConstTypePtr)&opaque, (GDExtensionConstTypePtr)&p_other_encoded);
}

String String::operator%(double p_other) const {
    double p_other_encoded;
    PtrToArg<double>::encode(p_other, &p_other_encoded);
    return internal::_call_builtin_operator_ptr<String>(_method_bindings.operator_module_float, (GDExtensionConstTypePtr)&opaque, (GDExtensionConstTypePtr)&p_other_encoded);
}

So, I had to resort to the most cumbersome way, using a switch statement to solve the issue where the Variant type couldn't be handled correctly.

switch (p_value.get_type())
        {
        case Variant::NIL:
            s = str % nullptr;
            break;
        case Variant::BOOL:
            s = str % bool(p_value);
            break;
        case Variant::INT:
            s = str % int64_t(p_value);
            break;
        case Variant::FLOAT:
            s = str % double(p_value);
            break;
.....
.....
.....
        case Variant::PACKED_COLOR_ARRAY:
            s = str % PackedColorArray(p_value);
            break;
        case Variant::PACKED_VECTOR4_ARRAY:
            s = str % PackedVector4Array(p_value);
            break;
        default:
            s = str % p_value;
            break;
        }

Minimal reproduction project (MRP)

1

[akien-mga]

Moving to the godot-cpp as it's related to its own implementation of String.

[dsnopek]

I'm really surprised to learn we have these operator%(...) methods in godot-cpp!

Since this isn't supported in Godot itself, having them goes against one of godot-cpp design goals, which is to support the same API as Godot. I think it might be better to remove these operators, rather than fix them. We appear to be automatically generating them based on the extension_api.json, so it'd be a matter of filtering them out in binding_generator.py.

Using vformat() would be the recommended way to do this kind of string formatting in godot-cpp