Export Dictionary With Type Hints

[zextillion]

Godot version:
3.1 Beta 2

Issue description:
You can export an Array with type hints to the editor so you don't have to deal with the drop-down list of types for every index. Why not do the same thing for dictionaries now that we can export them in 3.1?

Proposal:
You can export a dictionary with types for its keys and values like so:
export(Dictionary, key_type, value_type) var my_dictionary
In the inspector, we can only set keys with the corresponding key type and values with the corresponding value type, but we can still retain the ability to set keys and values to whatever type we want in code.

I think it would save a couple of seconds and brainpower when using exported dictionaries.

[syskrank]

Are there any updates on this case?
Or where should one look to start adding this functionality?
I'm messing around with gdscript_parser.cpp ( GDScriptParser::_parse_class(ClassNode* ) method ), but maybe there is some more solid flow rather than trial and error?

[bojidar-bg]

The change should be made in a few places:

1. gdscript_parser.cpp must be taught to understand the syntax.
2. The same file should produce a new hint_string for the property. (check how it is done with arrays for an example).
3. editor_properties_array_dict.cpp must be changed to understand the hint_string. (check how it is done with arrays for an example).

The hardest part of the problem will likely be in the first part. Here are some examples which are likely to be hard to support properly:

# Nesting with arrays
export(Array, Dictionary) var a # already works
export(Array, Dictionary, int, String) var b
export(Array, Dictionary, int, Array) var c
export(Array, Dictionary, int, Array, Dictionary, int, int) var d
export(Dictionary, int, Dictionary, int, int) var e

# Mixing with other type hints
enum X {A, B, C}
export(Dictionary, X, String) var f
export(Dictionary, X, X) var g
export(Dictionary, int, "a", "b", "c", String, "d", "e", "f") var h # enums
export(Dictionary, String, FILE, "*.tscn", String, "Optional", "Required", "Disabled") var i # files
export(Dictionary, int, -10, 10, float, EASE) var j # ranges, easing
export(Dictionary, NodePath, int, 10) var k # nodepaths
export(Dictionary, Vector3, int, "Seed", "Target") var l # vectors

# Not required, very fishy in practice:
export(Dictionary, Dictionary, int, String, int) var m # Dictionary<Dictionary<int, String>, int>
export(Dictionary, Dictionary, int) var n # Dictionary<Dictionary<?, ?>, int>
export(Dictionary, Array, int) var o # Dictionary<Array<?>, int>, very tricky
export(Dictionary, Array, Array, Dictionary) var p # Dictionary<Array<?>, Array<Dictionary>> or Dictionary<Array<Array<?>>, Dictionary>
export(Dictionary, Dictionary, Array) var q # Dictionary<Dictionary, Array<?>>
export(Dictionary, Array, Dictionary, Array, Dictionary) var r # Dictionary<Array<Dictionary>, Array<Dictionary>> or Dictionary<Array, Dictionary<Array, Dictionary>>

[syskrank]

So, the hint_string is needed for editor_properties_array_dict.cpp ?

I think that it would be wise to start from the simplest (?) case possible:

export(Dictionary, X, Y) var v

where X and Y are built-in (native?) types. In my case I want to add support for Resource/PackedScene keys and int values.

The parser comments and documentation are scarce, so it would be a huge undertaking to support every possible code construct from above in one go.

Imo, incremental/iterative approach will be the healthiest one.

If there are some docs on the subject, it would be very valuable to mention them here or in the official documentation.

[syskrank]

So, regarding the new syntax, at minimum, two methods are need to be modified:

GDScriptParser::_parse_class(ClassNode* p_class);
GDScriptParser::_parse_expression(Node* p_parent, bool p_static, bool p_allow_asign, bool p_parsing_constant);

The first one should allow the hint tokens to be passed down to recognition via expression solver/parser.

However, most of the time is spent on trying to figure out what does what.

[bojidar-bg]

@syskrank I feel you might need to add a new method in the long run: GDScriptParser::_parse_type_hint. It would try to parse a single type hint, so it can be called recursively.

[Calinou]

Closing in favor of godotengine/godot-proposals#56, as feature proposals are now tracked in the Godot proposals repository.