Typed `Dictionary<K, V>`

[Bromeon]

In addition to today's untyped VarDictionary type, we could add Dictionary<K, V> to the library, implementing Godot typed dictionaries.

This would have characteristics similar to Rust's HashMap<K, V>, with both K and V implementing ToVariant + FromVariant. Its API would be largely consistent with the existing Array<T>, notably with three types:

// Typed dictionaries.
struct Dictionary<K, V> {...}

// Untyped dictionaries.
type VarDictionary = Dictionary<Variant, Variant>;

// Type-erased dictionaries (either typed or untyped at runtime).
struct AnyDictionary {...}

Relevant links:

• Implement typed dictionaries godotengine/godot#78656
• Godot Dictionary API
• Rust HashMap API
• godot-rust Array<T> API

[Bromeon]

There was an idea to extend Array covariance even further, see #1434. This would allow treating arrays as (out) arrays to their base classes. I'm not sure if this is needed though, and worth the extra complexity.

[Bromeon]

I started working on this. Looks generally good, one problem is that in v0.4, VarDictionary (untyped) takes impl ToGodot arguments in a lot of places.

Since the new VarDictionary would just be Dictionary<Variant, Variant>, its methods would have to be generic. If we use AsArg<Variant>, that currently doesn't allow implicit conversions from all variant types:

let mut dict = VarDictionary::new();

// v0.4
dict.set("key", 123);

// current draft
dict.set("key".to_variant(), 123.to_variant());

This is of course not very nice. A few options:

1. Live with it.
   • This will also break a lot of existing code, for a UX downgrade.
2. Try to implement AsArg<Variant> for a lot of types.
   • not sure if T: ToVariant blanket impl is possible coherence-wise
   • defeats type inference in cases like array![1, 2, 3] that now become ambiguous (1 is i32 or Variant?)
3. Make an adapter trait in front of either AsArg<T> (for T != Variant) or ToGodot (for T == Variant).
   • might work but adds yet another conversion trait for this niche use case
4. provide convenience methods like set_v(key, value) taking ToGodot instead
   • trivial for Dictionary<Variant, Variant> but what about Dictionary<String, Variant> for example? Needs again messing with generics/traits

Array has the same problems, but it's usually less of an issue because arrays are much more often homogenous than dicts. Dictionaries often take a struct-like role, with string keys and heterogenous values... so it would be good to have decent usability for them.