Typed dictionary / struct / interface

[lobesoftllc]

Writing script can be long an tedious,
having a struct/interface typed dictionary would be very useful for auto-complete code, bug checks and some other request like #25157.
it also could be very useful for performance optimization as having a typed struct with linear memory should be much faster than a generic dictionary (if the actual interface is used like a struct and not a dictionary)

The typed dictionary could be declared like a class

interface alimentType:
var name:String
var type:int
var dmg_type:myAwesomeClass
var stack:bool
var lvl:anotherInterface

Although i'm not sure if the interface should have some other enhancement like the one you can find in typescript (just an example reference)

Anyway, i think that even a first basic support will help.

[Zylann]

Why not just make classes work? Dictionaries are meant to be able to contain anything. Classes are meant to make you to predeclare what's in them. So I think it should make more sense to work on classes than dictionaries.

[lobesoftllc]

Why not just make classes work? Dictionaries are meant to be able to contain anything. Classes are meant to make you to predeclare what's in them. So I think it should make more sense to work on classes than dictionaries.

Working with data, json, will be much better because classes still need to be manually create with .new()
and populated somehow, or i am missing something?
With nested data, working with classes can become a nightmare.
For the same reason i would like a typed array, something like Array (future request).

for now i'm talking about a hint for the inspector and the autocomplete code.

for all the other use case, yes, class is ok, if they work with the inspector #3597

[Zylann]

Working with data, json, will be much better because classes still need to be manually create with .new()
and populated somehow, or i am missing something?

Then there should be a way to instance them by name? For example, in C# deserializing JSON can be done by specifying which class to deserialize and fields and types of those fields are taken into account when going in and out of json because classes are such definition of data structure.

With nested data, working with classes can become a nightmare.

class A:
    var a: int
    var b: B

class B:
    var name: string

Like this? Same in C#, serialization libraries are able to detect nested types and serialize them accordingly, and that depends on declaring data structures with classes.

The only issue with GDScript is that you can't declare an array to contain custom types. It's either primitives (int, real, bool, Vector3 etc) or anything else, and if it's an object it has to either be Resource or Node to be editable, and that would be interesting to have for any structure. Not just for the inspector, but serialization as well so saving/reading pre-declared types would be easier and checked. But before we even get that on containers, getting arbitrary classes to work would be great too.
It's possible to make them work just for the inspector, but currently it requires an off-putting amount of boilerplate.

[DeadlyLampshade]

I reckon it would be cool if you could do something like this for exports. Currently the best way to do something structured like that is to override the various property functions, which absolutely requires the object be in tool mode and not exported.

[lobesoftllc]

Then there should be a way to instance them by name? For example, in C# deserializing JSON can be done by specifying which class to deserialize and fields and types of those fields are taken into account when going in and out of json because classes are such definition of data structure.

With nested data, working with classes can become a nightmare.

class A:
    var a: int
    var b: B

class B:
    var name: string

Like this? Same in C#, serialization libraries are able to detect nested types and serialize them accordingly, and that depends on declaring data structures with classes.

Yes, c# can do that because of reflection.
I'm losing my sight unfortunately,
should we have feature like reflection?
or just a serialization/deserialization function for those classes?

The only issue with GDScript is that you can't declare an array to contain custom types. It's either primitives (int, real, bool, Vector3 etc) or anything else, and if it's an object it has to either be Resource or Node to be editable, and that would be interesting to have for any structure. Not just for the inspector, but serialization as well so saving/reading pre-declared types would be easier and checked. But before we even get that on containers, getting arbitrary classes to work would be great too.
It's possible to make them work just for the inspector, but currently it requires an off-putting amount of boilerplate.

Hope that will change, Dictionary<T1,T2>, Array< T > maybe even better generic class Name< T >.
Even defining custom built-in objects like Vector2 could be useful.

I really feel powerless, i would like to make some additions to the language, it would be great to have a roadmap/todo list of feature and request for GDscript and start to work on matter.

[wytzen]

I would like to add that besides typescript, python now also has a similar feature. This is the relevant PEP: https://www.python.org/dev/peps/pep-0589/ . It also has a good motivation of why this feature is a nice thing.

I would also be interested in looking in to implementing this, but have never contributed to GODOT before. Would anyone know where to start looking with this?

[Calinou]

@wytzen Welcome! GDScript is currently undergoing a refactor. You should discuss this with @vnen on IRC (#godotengine-devel @ irc.freenode.net).

[mhilbrunner]

As Calinou pointed out, GDScript is getting reworked for Godot 4.0. See: #39093 :) Besides that:

---

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!