Why does Variant Serialize it's Signature?

[bbb651]

I'm trying to construct a zvariant::Value from ron using it's serde deserializer implementation, and I've discovered that it's serialized and deserialized in the following form:

struct zvariant::Value {
    "zvariant::Value::Signature": <signature>,
    "zvariant::Value::Value": <value>,
}

rather than just <value> like I've excepted. This is even more of a problem for my use case as ron doesn't support : in identifiers, and writing a custom deserializer that wraps the variant in the struct is non trivial as it requires generating the type signature from the value, which means it has to go through another conversion(?)

I was wondering why is it necessary to save the signature rather than infer it from the deserialized value.
The only problem I can see is that some types in the dbus specification that don't have equivalents in the serde data model and serializing them with anything that is a valid dbus value can collide with possible values (e.g. a struct named zvarient.something), but I think using tuple structs can work well for them (e.g. "struct Signature(string)" to represent signatures).

In any case, I think offering an additional deserializer that does infers the type and can
deserialize to a zvariant::Value directly would be really useful.

[zeenix]

D-Bus is not a self-describing encoding and hence a dynamic type must encoded the type information in it. This dynamic type in the D-Bus lingo is called a VARIANT, which the zvariant::Value represents.

I did try my best to have zvariant not require signatures in general but due to how serde and D-Bus work, certain cases were impossible to encoded/decode, e.g empty arrays. Hence unfortunately the need for signatures and zvariant::{Type, DynamicType}