Add static type hints for dictionary members

Describe the project you are working on:
Cutscene-heavy RPG

Describe how this feature / enhancement will help your project:
I want to associate some object with some identifier to make it easy to reference them from the AnimationPlayer (in this case it's some Dialogue class with data for who is talking and what they're saying.) I would like to access this data using the format read_dialogue(id: String), where the id is the key in a dictionary that leads to the data. This causes my extended AnimationPlayer to pause the animation so it can autotype some text and wait for player input before moving on with the animation.

However, there's currently no way to define a dictionary to have any particular kinds of keys and values, so if, for example, I wanted to add 50 different lines of text to read in this animation, I'd have to set the key's type and the value's type manually every time, which is tedious.

Furthermore: without dictionary hints, it's not possible to add a hint to a particular kind of Object, since the list of types you can pick from is limited to built-ins and various primitive types. Contrast this to arrays, where you can use hints to specify just about any type not present in the drop-down. So, you're not going to be able to easily create resources in-place, resulting in the OmniResource issue (except worse since it's every object ever.)

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

export(Dictionary, String, Resource) var hinted_dictionary

If this enhancement will not be used often, can it be worked around with a few lines of script?:
I think just about everyone will be very pleased with this addition; however, in the meantime, it's not too bothersome to avoid the issue. Instead I'll give my class an id: String property and loop through an array. I assume this isn't as efficient as using dictionaries, but I likely won't notice a real performance hitch. Nonetheless, it's a shame exported dictionaries can't be more useful.

godotengine/godot#25157

[RichardEllicott]

this would be really nice, yes at the moment for example i really wanted to add a dictionary such that i can add other types not on the list, for example:

<String, AudioStream> for a keyed list of sounds i can load from the inspector

we have it already with lists

[SoDaRa]

This would be a very nice feature. I'm doing a VN and would like to replicate the functionality of SpriteFrames in Animated Sprite to help pack all the images for a character into a scene to make it easier to compartmentalize. But using SpriteFrames causes all the images in it to be loaded, even if they aren't used. Which is understandable, but if we packed over 100 images into a character, suddenly it's going to eat up a lot of video memory and likely won't play nice with mobile. All I really need is the path to each image so I can load them when they're needed. So a Dictionary would be a perfect way to replicate the SpriteFrames resource when calling on the sprite with parameters of which sprite resources need to be loaded. But setting up the key and value type for hundreds of images is a chore. So this would help a lot.

[cgbeutler]

While I don't know/care what the short-hand export syntax would look like
It seems like typing exports for dictionaries and arrays may be better as a more "deep" style. I think this has been mentioned elsewhere, but I couldn't find it. The 'property info' dictionaries are used all over, like for function parameters and return values. The 'property info' syntax could be used here as well to hold sub-types. This may actually reduce complexity in some places.

In the context of _get_property_list it may look something like:

func _get_property_list() -> Array:
  return [
    { name = "my_dict", type = TYPE_DICTIONARY,
      hint_types = [
        { type = TYPE_STRING }, #key property
        { type = TYPE_INT, hint = PROPERTY_HINT_RANGE, hint_string = "0,10" }, #value property
      ]
    }
  ]

The above somewhat mimics the "Generics" list in some languages, which may also play well when hooking c# in.
I imagine the name field could be added for subtypes, if that seems like its easier. It is usually ignored for function return types and a few other spots.

The editor itself could then do a more recursive-ish rendering of inspectors when it comes to Dictionaries or Arrays. There would be no real depth-limit to the underlying representation.
The short-hand export may still have a depth limit, but there would be a long-hand way to get around it, if needed.

As array stands in 3.3, export(Array, Array, float) var arr := [] will give you the property info {class_name:, hint:24, hint_string:19:3:, name:arr, type:19, usage:8199}. The hint string '19:3:' appears to just be a concat of type enums, which kinda cuts out any options or custom resources.

[chexmo]

I came here from godotengine/godot#25157 since someone said that that issue continues here.
I want to know if there are any news related to exporting dictionaries...
As you can see in the image below, in godot 3.4.3 it still doesn't support typed dicts

[Calinou]

I want to know if there are any news related to exporting dictionaries...

This feature isn't planned for 4.0, as we don't intend to add new features to GDScript to ensure it can stabilize for 4.0.