GDScript's new Struct-like types

[nlupugla]

Hi Godot community! I have been having a lot of fun implementing the proposal by @reduz #7329 for adding struct-like types to GDScript. That proposal was mainly concerned with how to implement structs as Arrays with individually named and typed elements. It briefly discussed the syntax for using them in GDScript and C++, but did not go in to details on how this new feature should behave.

I'd like to open a channel for discussing the nitty gritty details of structs as a language feature in GDScript. To be clear, I don't want to discuss how they will be implemented, that is better discussed in the original proposal. I've listed below a few of the questions that I'm currently puzzling over.

For the sake of concreteness, let's consider a struct defined in GDScript like so:

struct NamedInt:
	var name : String
	var value : int

Question 1: What should the syntax be for creating a struct instance?

Some possibilities:
a)

var named_int := NamedInt(name = "Godot",  value = 4)

b)

var named_int : NamedInt = [name = "Godot", value = 4]

Question 2. When should two structs be considered equal?

var named_int := NamedInt(name = "Godot", value = 4)

var same_reference := named_int  # same_reference == named_int should obviously be true
var same_struct := NamedInt(name = "Godot", value = 4)  # but what about same_struct == named_int
var same_names_and_values := OtherNamedInt(name = "Godot", value = 4) # or same_names_and_values == named_int
var same_values := ["Godot", 4]  # or same_values == named_int ?

Question 3. How should structs appear in documentation?

Suppose a function returns a NamedInt. Here are some ways that fact could be displayed in documentation.

a) NamedInt
b) Struct[String, int]
c) Array{String, int}
d) [name : String, value : int]

More to come...

There are many more questions to be answered about the new struct-like type. I'll try to update the post with particularly hairy ones that are brought up in the discussion.

Looking forward to hearing everyone's ideas!

Edit December 13 2023, 9:54:

Thanks for the discussion so far everyone! There seems to be a consensus that when it comes to creating a struct, the

var named_int := NamedInt(name = "Godot",  value = 4)

syntax is preferred over something like

var named_int : NamedInt = [name = "Godot", value = 4]

Another question has come up as I've been working on structs.

Question 4. How should structs be formatted when printed?

For example, what should the following output?

var named_int := NamedInt(name = "Godot",  value = 4)
print(named_int)

Here are some of the options I'm considering.

a) [name: "Godot", value: 4]
b) {name : String = "Godot", value : int = 4}
c) NamedInt(name = "Godot", value = 4)

What do you think?

Edit January 11 2024, 10:46:

@AndrewAPrice has brought up some interesting questions about duck typing and when two structs should be considered equivalent.

These are related to my question 2 above, but go a step further by looking at cases where one struct has the same fields as another but in a different order or one struct has more fields than other.

For example, let's consider a few different structs.

struct NamedInt:
    var name : String
    var value : int


struct Named:
    var name : String


struct NamedValue:
    var name : String
    var value : Variant


Struct IntNamed:
    var value : int
    var name : String


var named_int := NamedInt(name = "named_int", value = 3)
var named := Named(name = "named")
var named_value := NamedValue(name = "named_value", value = "not an int")
var int_named := IntNamed(value = 5, name = "int_named")

With these in mind, we can think about which of the following structs should and should not support. The lines in the following code block are meant to be read in their own context, not as sequential instructions.

# upcasting -----

# implicit upcast
named = named_int
# explicit upcast
named = named_int as Named
# explicit up-construction
named = Named(named_int)


# down casting -----

# implicit downcast
named_int = named
# explicit down cast
named_int = named as NamedInt
# explicit down construction
named_int = NamedInt(named)


# permutation casting -----

# implicit permutation cast
named_int = int_named
# explicit permutation cast
named_int = int_named as NamedInt
# explicit permutation construction
named_int = NamedInt(int_named)


# recursive upcasting -----

# implicit recursive upcast
named_value = named_int
# explicit recursive upcast
named_value = named_int as NamedValue
# explicit recursive construction
named_value = NamedValue(named_int)


# recursive down casting -----
# I think you get the picture by now

# recursive permutation casting -----
# I think you get the picture by now

In each of these situations, I could imagine a few different levels of support

1. Supported by runtime and analyzer
2. Supported by runtime, but analyzer emits a warning
3. Supported by runtime, but analyzer emits an error
4. Runtime emits warning, analyzer emits warning
5. Runtime emits error, analyzer emits error
6. Runtime crashes, analyzer emits error

Taken together, these amount to A LOT of questions to be answered, but I think they are pretty important design decisions that should not be made lightly. This is my personal stance at the moment, but it could easily be swayed by a good argument.

• Implicit upcasts and permutation casts should be supported at runtime, but trigger an analyzer warning
• Explicit upcasts, up constructions, permutation casts, and permutation constructions should be fully supported
• Implicit and explicit downcasts should crash runtime and trigger an analyzer error
• Explicit down construction should be fully supported
• Same stance for all the recursive versions

My reasoning at the moment is loosely based on how subtype polymorphism is defined in the textbook Types and Programming Languages.

What do you all think?

Edit October 6 2024, 13:44:

Hi all, it's been a while since I've updated this discussion, but as my work on adding Structs to GDScript is nearly ready to review, I have encountered another essential question.

Question 5. When (if ever) should casting between Structs and Arrays or Dictionaries be automatic?

Consider the following example.

struct NamedInt:
    var name : String
    var value : int


var named_int := NamedInt(name = "Godot", value = 4)

named_int = ["Godot", 5]                              # should Array to Struct be automatic?
named_int = {named = "Godot", value = 4} # should Dictionary to Struct be automatic?


var array := []

array = NamedInt(name = "Godot", value = 4) # should Struct to Array be automatic?


var dictionary := {}

dictionary = NamedInt(name = "Godot, value = 4) # should Struct to Dictionary be automatic?

Each of the cases above will certainly work if the user adds the appropriate explicit cast using as, but the question is if the casts should occur implicitly as well. I am inclined to say that these kinds of casts should never be implicit, but I can also see the appeal of being able to write the very concise named_int = ["Godot", 5] over the more verbose named_int = NamedInt(name = "Godot", value = 5) or named_int = ["Godot", 5] as NamedInt.

I'm interested to hear what you all think.

[Braveo]

1. For creating a struct instance, I'm mixed on either option. A looks a lot better for me because of how well defined the struct is, but B looks nice because it closely aligns with dictionaries, which is what structs are extending the usage of. I think A might be the ultimate better option for me though, but I'm indifferent.
2. I think two structs should be equal based on data, not on reference, and maybe use another form of comparison in order to compare the reference, but I'm not sure. I think structs should only be compared by type, and if you want to compare individual data, you compare struct1.value == struct2.value. I'm ultimately indifferent from this as well.
3. I definitely prefer A, but if structs are to be more like dictionaries in GDScript, then probably B or D.

I'm more of a static typer with defined structs and types, so I'm very rigid when it comes to structs, but since it's GDScript, I understand that people prefer more flexibility when it comes to how the data's represented.

This is definitely about no other language other than GDScript, but if we were to be attaching bindings, I hope they can be represented as language-specific structs rather than array-like structs. That's just my take on this, though.

[Stwend]

1. I'm tending towards a), as it would move structs more towards classes in the mind of the user and strenghten the differentiation between structs as a fixed structure ("a class without functions") and dictionaries as a loose structure and might make it easier for users to decide which one to use.

2. I think same_struct == named_int should apply. A struct's "class name" in most cases is a description of either contents or purpose, imo that makes it part of the data a struct holds and worthy of comparison
   same_names_and_values == named_int and same_values == named_int would lead to identifying structs that serve different purposes as being equal. I'd prefer those to be handled by helper methods, e.g. named_int.equals_values(other_named_int) and named_int.equals_names_values(other_named_int).

Another question that's just occurred to me is should subsets of names and/or values suffice for considering them equal?

struct NamedInt:
	var name : String
	var value : int

struct NamedIntExtra:
	var name : String
	var value : int
	var extra : int

var named_int := NamedInt(name = "Godot",  value = 4)
var extra_int := NamedIntExtra(name = "Godot",  value = 4, extra = 0)

What would named_int.equals_names_values(extra_int) and named_int.equals_values(extra_int) return?

3. a), for the same reasons as in 1.

[nlupugla]

I Like your idea in point 2. to make the default == operator care about the struct's name and to supply helper methods that check value equality or value and name equality.

For structs that are the same except for having extra values, I would lean against considering them equal. It seems like it has the potential to do more harm than good, but maybe there are some cases where that kind of equality would be really convenient?

[Stwend]

For structs that are the same except for having extra values, I would lean against considering them equal.

I feel the same way. To be honest, I'm not able to come up with a single use case where considering them equal would be beneficial, it just struck me as an edge case and I wanted to see if others had use cases where it'd either benefit them or give them headaches.

[AndrewAPrice]

I agree. This is enough of a edge case that if the user wanted a partial comparison between two structs they could write their own comparison function.

[idbrii]

I think that while the other proposal describes structs implemented in terms of dictionaries, they shouldn't expose their implementation to users. They should be convenient and clear in their own way instead of being dictionary-like because of their implementation. It should be reasonable to change the implementation of a performance -focused feature away from dictionaries in the future.

1: What should the syntax be for creating a struct instance

My experience with Godot's type inference implies that the first indicates that the following two are valid:

var named_int : NamedInt = [name = "Godot", value = 4]
var named_int := [name = "Godot", value = 4] as NamedInt
var named_int := [name = "Godot", value = 4] # surely not correct!

So I'd prefer the NamedInt(...) option A since it's less confusing and makes it easier to search for structs uses by name.

However, given that classes are created with new and scenes with instantiate, it might be good for structs to have a similar function to make it easier to find allocations. It's probably least confusing to share with classes:

var named_int := NamedInt.new(name = "Godot",  value = 4)

2. When should two structs be considered equal

I think the answer for this depends on whether the implementation makes structs types behave like golang interfaces: allows OtherNamedInt to be passed to a function expecting NamedInt because they have the same data. (structural typing)

same_values == named_int definitely shouldn't work because I think struct content should be protrayed as named and not ordered to prevent bugs with incorrect ordering. But something similar with a dictionary might be reasonable if they are structurally typed. If not, they should probably behave like classes.

3. How should structs appear in documentation

If a function returns a struct with 10 fields or a struct containing other structs, only A (NamedInt) is a reasonable option. I think we should generally lean in the direction of taking advantage of it being named instead of the content.

[IntangibleMatter]

I personally think that A is way more clear in what it's doing, and I think that for documentation option a is also better.

When it comes to equality, here's my two cents.

struct Foo:
    var a : int
    var b : String

struct Bar:
    var a : int
    var b : String
    var c : bool = false

var structa := Foo(a = 0, b = 1)
var structb := Bar(a = 0, b = 1, c = true)

# structa == structb should be false, as their absolute contents are different.

Because it doesn't make sense for two structs with different sets of variables to be equal (even if their contents are the same), I propose a method which checks all the variables with shared names for equality.

Something like

# returns true, because `a` and `b` have the same values in both.
structa.named_parameters_equal(structb)

Obviously this needs more clarification on how it should work (some people may want floats with no decimal point and ints to be treated as equal for reasons), but I think that a few functions for checking equality of structs with names/positional values/etc, would be the best solution for this.

[azur-wolve]

Question 1 → a)

Question 2 → same reference; the rest of options (same type structs, same name, same value, and same name and value and struct type, etc etc) should be evaluated with operators and auxiliary methods.

Question 3 → definitely not [] and {} for its members to avoid confusion with arrs and dicts.

// various options:

NamedInt method()

struct(NamedInt) method()

(struct) NamedInt method()

struct NamedInt method()

NamedInt(num: int, node: Node) method() [this one is too verbose]

[seocwen]

I'd rather prefer something more dictionary-based. I'm assumed they will be otherwise used very much the same as dictionaries even if the implementation is very different. Putting square braces, or the like is more likely to confuse users as to how structs are used--even if the implementation is more array like, that's not a detail the user needs to care about.

Let me just spitball something like:

struct my_struct {name = "Godot", value = 4}

With static typing
struct my_struct {name := "Godot", value = 4: int}

I think that, as with "enum," a struct should be kind of its own thing, not introduced by var.

I'm not certain what I think about equality. My usual inclination would be to say that my_struct is a type, and only objects of the same type are equal, but for duck-typed languages that might not be so useful. I guess the question becomes, for what purpose has the user created objects with the same signature but different aliases?

[nlupugla]

Using curly braces over square braces makes sense to me for the reasons you mentioned. It also begs the question of how structs should be printed. I've updated my original post to elaborate on that question.

[AndrewAPrice]

I like the idea of duct-typing (if two structs have the same fields, allow them to freely being assigned to each other).

What do you think about being able to upcast structs? The ability to assign a value of struct A to struct B, if A contains all of the fields needed by B.

struct ThingThatCausesDamage:
	var damage : int

struct Human:
        var name : String
        var damage : int

struct Tree:
        var species : String
        var damage : int

func calculate_damage_between_two_objects(a : ThingThatCausesDamage, b : ThingThatCausesDamage):
       return a.damage + b.damage

var human := Human(name = "Andrew", damage = 10)
var tree := Tree(species = "Poplar", damage = 5)

print ("Damage caused by human hitting the tree tree: %d" % calculate_damage_between_two_objects(human, tree))    

[nlupugla]

Upcasting structs seems like a very reasonable and useful trait to me. We would have to be very careful about where such upcasts are allowed to happen implicitly though.

For example, what is the value of ThingThatCausesDamage(damage = 4) == Human(name = "Andrew", damage = 4)? If Human upcasts to ThingThatCausesDamage in this context, then it evaluates to True. This might be okay, but might also be too sneaky for some people's tastes. I could see implementing some kind of an implicit cast warning for such cases and providing a syntax for explicit casts where needed, e.g. ThingThatCausesDamage(damage = 4) == Human(name = "Andrew", damage = 4) as ThingThatCausesDamage.

[AndrewAPrice]

Wdyt about struct == struct returning false if the types aren't duck-equivalent?

Requiring casting, e.g. ThingThatCausesDamage(damage = 4) == (Human(name = "Andrew", damage = 4) as ThingThatCausesDamage) would be reasonable.

[AndrewAPrice]

If we arranged the struct fields in memory alphabetically, then in this example:

struct A:
        var type : String
        var name : String

struct B:
        var name : String
        var type : String

struct A and struct B would have the same memory layout and casting between them would be free/0-copy. Internally, (Upcasting though would require copying as you'd have to compress the data around the missing fields.)

If we were to consider A and B equivalent, then A and B could be implemented as aliases over a name-mangling the struct fields. e.g. A and B could be both represented internally as a type named struct,name:String,type:String.

[nlupugla]

I'm not sold on having such a low level dependence on how exactly you've named your fields. I'm leaning toward towards struct A and struct B never being considered equivalent, unless one is explicitly cast into another.

Your comments bring up interesting questions about how structs should interact with the as operator as well as whether constructors like ThingThatCausesDamage(my_human) should be supported.

I'll edit my OP with a clearer statement of these questions.

[nlupugla]

For the benefit of folks that mostly interact with these discussions via email notifications, I'm copying a fairly lengthy update I've made to my OP.

@AndrewAPrice has brought up some interesting questions about duck typing and when two structs should be considered equivalent.

These are related to my question 2 above, but go a step further by looking at cases where one struct has the same fields as another but in a different order or one struct has more fields than other.

For example, let's consider a few different structs.

struct NamedInt:
    var name : String
    var value : int


struct Named:
    var name : String


struct NamedValue:
    var name : String
    var value : Variant


Struct IntNamed:
    var value : int
    var name : String


var named_int := NamedInt(name = "named_int", value = 3)
var named := Named(name = "named")
var named_value := NamedValue(name = "named_value", value = "not an int")
var int_named := IntNamed(value = 5, name = "int_named")

With these in mind, we can think about which of the following structs should and should not support. The lines in the following code block are meant to be read in their own context, not as sequential instructions.

# upcasting -----

# implicit upcast
named = named_int
# explicit upcast
named = named_int as Named
# explicit up-construction
named = Named(named_int)


# down casting -----

# implicit downcast
named_int = named
# explicit down cast
named_int = named as NamedInt
# explicit down construction
named_int = NamedInt(named)


# permutation casting -----

# implicit permutation cast
named_int = int_named
# explicit permutation cast
named_int = int_named as NamedInt
# explicit permutation construction
named_int = NamedInt(int_named)


# recursive upcasting -----

# implicit recursive upcast
named_value = named_int
# explicit recursive upcast
named_value = named_int as NamedValue
# explicit recursive construction
named_value = NamedValue(named_int)


# recursive down casting -----
# I think you get the picture by now

# recursive permutation casting -----
# I think you get the picture by now

In each of these situations, I could imagine a few different levels of support

1. Supported by runtime and analyzer
2. Supported by runtime, but analyzer emits a warning
3. Supported by runtime, but analyzer emits an error
4. Runtime emits warning, analyzer emits warning
5. Runtime emits error, analyzer emits error
6. Runtime crashes, analyzer emits error

Taken together, these amount to A LOT of questions to be answered, but I think they are pretty important design decisions that should not be made lightly. This is my personal stance at the moment, but it could easily be swayed by a good argument.

• Implicit upcasts and permutation casts should be supported at runtime, but trigger an analyzer warning
• Explicit upcasts, up constructions, permutation casts, and permutation constructions should be fully supported
• Implicit and explicit downcasts should crash runtime and trigger an analyzer error
• Explicit down construction should be fully supported
• Same stance for all the recursive versions

My reasoning at the moment is loosely based on how subtype polymorphism is defined in the textbook Types and Programming Languages.

What do you all think?

[madeleineostoja]

I haven’t followed this discussion too closely but from the update examples you just posted I agree with all points of your stance, especially with downcasting throwing errors unless it uses the constructor

[unfallible]

It looks to me like a number of these questions boil down to whether the GDScript structs should be nominally or structurally typed. For my part, I prefer nominal typing, and I essentially agree with @Stwend's claim that

A struct's "class name" in most cases is a description of either contents or purpose, imo that makes it part of the data a struct holds and worthy of comparison

Since I think that the answers to most of the questions posed in this thread become fairly straightforward if we accept the premise that a struct's type should be considered part of its identity, I'd like to offer a more robust defense of this position.

I'm skeptical of the sort of structural typing ideas being floated here for a couple reasons.

1. My first concern is that this seems like it would be inconsistent with the way that Godot already treats types, which is why it hadn't occurred to me that struct types might be treated this way in the first place. Modern GDScript is "duck-typed" only in the sense that when you call a method or property on an object whose type is unknown, it looks up the implementation using the name of that property and does as much as it can. Yet even then, values (always?) have a unique type, which can be tested at runtime using the is operator or the typeof() and get_type() functions. You can't cast between classes just because they have the same properties and methods with the same types. When you test class instances for equality, GDScript won't treat objects as equal just because they share the same properties and values (in fact, it will test the references). In other words, GDScript is, for all intents and purposes, a nominally typed language. I think it would be unnecessarily confusing if we said that structs are structurally typed, but objects are nominally typed. I'll grant letting the properties of an object be sufficient to determine its identity is consistent with their history as dictionaries, but I also think that this is one of the reasons why using dictionaries as pseudo-structs is a bad idea.

2. My second reason is that structural typing makes it too easy to create unintended relationships between structs. Struct types will presumably have unique names, just like every other type in Godot. This makes them well suited to provide all of the context for the meaning of their properties. I think that property names should really only have meaning in the context of their particular type. The fact that my PastryChef and Gangster classes can both make_some_dough() should be treated as coincidental rather than reflective of some deep ontological truth about the relationship between crime and cuisine. To appreciate this point, I'd like to consider @AndrewAPrice 's ThingThatCausesDamage example in depth.

The ThingThatCausesDamage Example

I like the idea of duct-typing (if two structs have the same fields, allow them to freely being assigned to each other).

What do you think about being able to upcast structs? The ability to assign a value of struct A to struct B, if A contains all of the fields needed by B.

struct ThingThatCausesDamage:
	var damage : int

struct Human:
        var name : String
        var damage : int

struct Tree:
        var species : String
        var damage : int

func calculate_damage_between_two_objects(a : ThingThatCausesDamage, b : ThingThatCausesDamage):
       return a.damage + b.damage

var human := Human(name = "Andrew", damage = 10)
var tree := Tree(species = "Poplar", damage = 5)

print ("Damage caused by human hitting the tree tree: %d" % calculate_damage_between_two_objects(human, tree))    

My intuition is that neither upcasting nor any of the other forms of casting and construction described by @nlupugla should be legal. Upcasting would be beneficial in the ThingThatCausesDamage example, but I think it would be dangerous in other cases. Consider the following struct:

struct RealEstateListing:
	var square_footage: float
	var name: String
	var address: String
	var owner: String
	var value: int
	var sticker_price: int

var palace_listing: RealEstateListing = RealEstateListing(
	name = "Buckingham Palace",
	square_footage = 828,821,
	owner = "King of England",
	address = "London SW1A 1AA, UK"
	value = 999999999999
	sticker_price = 9999999999999999999)

var test_result: NamedInt = NamedInt(palace_listing)
print(test_result) # NamedInt(name = "Buckingham Palace", value = 999999999999)

Because RealEstateListing has all of the properties that the NamedInt struct has, I am being allowed to construct a NamedInt from a RealEstateListing, yet the result of this operation is nonsensical. When I look at the definition of the NamedInt struct, I can intuit that its purpose is to define a value or measurement with the value property, and pair that with a description of what is being measured in the name property. When I look at RealEstateListing, I can similarly intuit that RealEstateListing instances describe a piece of real estate with a name and a certain monetary value. In the case of the palace_listing variable, the RealEstateListing is a listing for Buckingham Palace, which is worth 999999999999 (GBP, I guess?). Yet when we construct test_result from this we get a struct instance whose meaning is ambiguous at best. If we wanted to create a NamedInt whose value was palace_listing.value, it seems like an appropriate value for name would be something like "buckingham_palace_worth", "price", or even just "value". Instead, we've ended up with the name "Buckingham Palace", the interpretation of which is highly ambiguous (is 999999999999 the price of Buckingham Palace? Its square footage? Maybe it's something completely different). Yet the purpose of the NamedInt was that its name was intended to clarify the meaning of its value. Since constructing a NamedInt from a RealEstateListing defeats the purpose of constructing a NamedInt, doing so probably shouldn't be legal.

If property names and types were sufficient to determine a struct instance's type, I would have to consider the property names and types of every single struct type in my project any time I go to define a new struct. To demonstrate this, let's build on the ThingThatCausesDamage example. Suppose that I've created a project which uses the code from ThingThatCausesDamage. However, now that I have this infrastructure in place, I'm ready to do things with the damage that being caused. In other words, I need a ThingThatTakesDamage struct. What's the most obvious name for a property which tracks damage? It's "damage." If I wasn't careful, I could very easily end up with the following struct definition:

struct ThingThatTakesDamage:
    var damage : int

This would enable the same bizarre behaviors described in the RealEstateListing example. Suppose I implement ThingThatTakesDamage with a damage property, and then regret it later down the line. In order to fix it, I would have to change the variable name and every single access to that variable in my code. If I really wanted to do it right, I would probably have to change the damage variable in both struct definitions to clarify what they both mean and avoid future name conflicts. Now suppose that I decided much later I also wanted some kind of event struct for when an object is damaged. Then I would have to come up with another way to say "damage" that does not accidentally end up implying that my ObjectDamaged event was intended "inherit" from any of the structs with a small number of parameters related to the concept of damage.

Avoiding unintended relationships would be especially important when defining structs to be used in an API. In this context, I must document which name conflicts are intentional, which takes work for me to write and work for my users to read. If I overlook something, my users will need to guess my intentions about these name conflicts, which still takes work, and if they guess wrong they get undefined behaviors. All of this creates more work for the both the API authors and users.

One last thing I'd point out these special casts is that if they're added up front and then proves to be a bad idea which experienced developers all decide never to use while new users stumble over (think multiple inheritance of concrete classes in C++), we would be stuck with it until the next major version Godot at least. On the other hand, if it turns out to be something people really want that can't be better expressed in some other way (for example, if Traits never get added), these things can be added later down the line.

Despite my reservations about equivocating between different struct types because they're structurally similar, I think that the ThingThatCausesDamage case demonstrates a legitimate need for ways to define relationships between different struct types. I would propose a two part alternative for addressing this need.

Instantiating structs with static functions

The first tool I think we should have for specifying relationships between struct types is the ability to define static functions in a struct's "namespace." This approach would make it easy to define new ways to instantiate structs based on other structs. Here's an an example of how this might work in the original ThingThatCausesDamage example:

struct ThingThatCausesDamage:
	var damage : int

struct Human:
	var name : String
	var damage : int
	static func as_ThingThatCausesDamage(a: Human)->ThingThatCausesDamage:
		return ThingThatCausesDamage(damage = a.damage)

struct Tree:
	var species : String
	var damage : int
	static func as_ThingThatCausesDamage(a: Tree)->ThingThatCausesDamage:
		return ThingThatCausesDamage(damage = a.damage)

func calculate_damage_between_two_objects(a : ThingThatCausesDamage, b : ThingThatCausesDamage):
	return a.damage + b.damage

var human := Human(name = "Andrew", damage = 10)
var tree := Tree(species = "Poplar", damage = 5)

print ("Damage caused by human hitting the tree tree: %d" % calculate_damage_between_two_objects(
	Human.as_ThingThatCausesDamage(human), 
	Tree.as_ThingThatCausesDamage(tree)))

Defining type conversions in static functions which are scoped to struct type names is safe and flexible, but the syntax is cumbersome. Moreover, this approach has the disadvantage that it doesn't let us use the same instance as multiple types. Instead, it is constructing a new instance of the target type based on the old one. For example, if you have a Heal(target: ThingThatTakesDamage) function, you probably want to heal the original ThingThatTakesDamage rather than a copy of it.

Allowing structs to implement certain Traits

The second tool I would propose for specifying relationships between struct types involves the Trait feature proposed in #6416. The idea would be to allow structs to implement a Traits as long as the Trait only contains properties.

trait ThingThatCausesDamage:
	var damage : int

struct Human:
	implements ThingThatCausesDamage
	var name : String

struct Tree:
	implements ThingThatCausesDamage
	var species : String
	
func calculate_damage_between_two_objects(a : ThingThatCausesDamage, b : ThingThatCausesDamage):
	return a.damage + b.damage

var human := Human(name = "Andrew", damage = 10)
var tree := Tree(species = "Poplar", damage = 5)

print ("Damage caused by human hitting the tree tree: %d" % calculate_damage_between_two_objects(human, tree))

Note that this approach is dealing directly with the human and tree objects, rather than copies. Also note that by using Traits we would be able to define contracts which could be fulfilled by either classes or structs. This has the advantage of flexibility, but although it may also come performance penalties (I don't know enough to evaluate that question).

Addressing the original questions

Having hopefully made a convincing argument for treating type as part of a struct's identity, let me explain my position on @nlupugla's original 4 questions.

Question 1: What should the syntax be for creating a struct instance?

Some possibilities: a)

var named_int := NamedInt(name = "Godot",  value = 4)

b)

var named_int : NamedInt = [name = "Godot", value = 4]

It sounds like the a consensus here is a). I basically agree with this, although I think it's a little verbose. Letting people use the struct's "namespace" to define static functions would help with the verbosity here though. For example, we could have something like

struct NamedInt:
	var name : String
	var value : int
	static func init(name: String = "Default", value = 0) -> NamedInt:
		return NamedInt(name = name, value = value)

which would let the NamedInt be initialized by calling NamedInt.init(). This would convenient to write, use, and read.

Question 2. When should two structs be considered equal?

var named_int := NamedInt(name = "Godot", value = 4)

var same_reference := named_int  # same_reference == named_int should obviously be true
var same_struct := NamedInt(name = "Godot", value = 4)  # but what about same_struct == named_int
var same_names_and_values := OtherNamedInt(name = "Godot", value = 4) # or same_names_and_values == named_int
var same_values := ["Godot", 4]  # or same_values == named_int ?

I have a slight preference for saying same_struct == named_int should be false. I would give three reasons for this:

1. GDScript doesn't seem to be consistent in its treatment of the == operator. Classes test equality by comparing references, while Arrays and Dictionaries test equality by comparing their values. My general desire is for structs to behave like a specialized type of class which trades flexibility for performance rather than a Dictionary with autocompletion and type hints, so it seems appropriate to me that the == operator should behave the same way for structs and classes.

2. The value-based equality test is expressible using existing operations (e.g. static func equals(a: NamedInt, b: NamedInt)->bool: return a.name == b.name && a.value == b.value), while the reference-based equality test is not. If the == operator does end up comparing structs' values rather than their references, I think structs should be given an equivalent to Array's id() function for comparing the references.

3. Related to point 2, my intuition is that in general, more complex operations should have more verbose syntax. That said, I also think more commonly used operations should have less verbose syntax, and I appreciate that there's an argument to be made that people want to compare values more often than they want to compare references.

With respect to same_names_and_values and same_values cases, I feel strongly that neither same_names_and_values nor same_values should be treated as equal to name_int since I think that type should be part of a struct's identity.

Question 3. How should structs appear in documentation?

Suppose a function returns a NamedInt. Here are some ways that fact could be displayed in documentation.

a) NamedInt b) Struct[String, int] c) Array{String, int} d) [name : String, value : int]

I feel that a) is the best choice here. If a struct's type is part of its identity, then it follows that the documentation should make it clear what type of struct is being returned. This has the added benefit of being more concise.

Question 4. How should structs be formatted when printed?

For example, what should the following output?

var named_int := NamedInt(name = "Godot",  value = 4)
print(named_int)

Here are some of the options I'm considering.

a) [name: "Godot", value: 4] b) {name : String = "Godot", value : int = 4} c) NamedInt(name = "Godot", value = 4)

If a struct object's type should be considered a salient part of it's identity, and we want printing an object to tell us the salient details about that object, then it follows that c) is the best choice here.

Concluding remarks - Looking towards unions in GDScript

I came to this thread from the Union proposal (#737), which I'm currently drafting a response to. The summary of what I intend to say there is that I would like to see GDScript add the ability to constrain the types of Variants by using typehints with the syntax T1 | T2. Among other things, this would allow users to emulate the behavior of tagged unions like so (this example is adapted from Rust's docs ):

struct WebEvent:
	# !!! Nested struct definitions !!!
	stuct PageLoad:
		pass # !!! Note that while this struct has no members, instances still contain data because type IS data
	struct PageUnload:
		pass
	struct KeyPress:
		var key: int
	struct Paste:
		buffer: String
	struct Click:
		var coords: Vector2
	# equivalent to "var event_type: Variant" when compiled, but gives the analyzer more info to ensure correct usage
	var event_type: PageLoad | PageUnload | KeyPress | Paste | Click

which could then be queried using the "is" operator:

func on_web_event(event: WebEvent):
	if event.event_type is WebEvent.PageLoad:
		print("page loaded")
	else if event.event_type is WebEvent.PageUnload:
		print("page unloaded")
	else if event.event_type is WebEvent.KeyPress:
		print("pressed '%s'." % event.event_type.key)
	else if event.event_type is WebEvent.Paste:
		print("pasted \"%s\"." % event.event_type.buffer)
	else if event.event_type is WebEvent.Click:
		print("clicked at %s." % event.event_type.coords)

Support for robust pattern matching would also need to added, so the static analyzer could ensure that every possible to type is being tested, but it would compile to code which would be roughly equivalent to the code above. I intend to flesh out the details of this approach and argue for its advantages in the appropriate thread, but the upshot for our purposes is that if a struct's type is not treated as part of its identity at runtime, a feature like this would be impossible to implement properly. For example, instances of WebEvent.PageLoad and WebEvent.PageUnload would always be equal, and depending on how the is operator is implemented, potentially indistinguishable.

EDIT: Fixed the WebEvent example.

[nlupugla]

Thanks for the well-written and thorough writeup!

Broadly speaking, I agree with you that structs should lean more towards nominal typing than structural typing. As I agree with most of your points, I'll just respond to the things I'm not totally sold on.

1. I could be convinced that implicit casts make the struct type system too weak, but I do think there should be a convenient way to explicitly cast. Passing a RealEstateListing directly to a NamedInt parameter could certainly lead to confusion over what the name field is meant to represent. However, I see forcing the user to write NamedInt(real_estate_listing) or real_estate_listing as NamedInt, as a way of saying, "are you sure that it makes sense to treat a RealEstateListing as a NamedInt? If it doesn't, but the user writes it anyway, I would call it a user error rather than a type error.
2. I'm not a big fan of having static methods attached to structs. For one thing, not having to deal with methods makes implementing and maintaining structs considerably simpler. For another, structs have to live inside a class, so you could always make the static method part of the surrounding class rather than the struct itself. It is a shame that GDScript doesn't have a way to create namespaces independent of class_name yet, but I think that problem is orthogonal to structs.

Thanks again for engaging here with such a well-thought out comment!

[unfallible]

Hello. Thanks for the reply.

I could be convinced that implicit casts make the struct type system too weak, but I do think there should be a convenient way to explicitly cast. Passing a RealEstateListing directly to a NamedInt parameter could certainly lead to confusion over what the name field is meant to represent. However, I see forcing the user to write NamedInt(real_estate_listing) or real_estate_listing as NamedInt, as a way of saying, "are you sure that it makes sense to treat a RealEstateListing as a NamedInt? If it doesn't, but the user writes it anyway, I would call it a user error rather than a type error.

Personally, I dislike anything that adds behaviors to my APIs without my consent, and the lack of scalability of explicit casts makes think it's a feature I would never use in my own code. That drives my other concern; I can't think of any scenarios where an experienced developer would want to use this feature instead of another like traits, but I can think of many scenarios where a beginner would think that they want it and then screw themselves over with it. That concern is what drew the comparison to multiple inheritance of concrete classes in C++. Perhaps you can show me some examples of problems where, given the option to use Traits, helper functions, and explicit casts, explicit casts would be the solution least likely to incur technical debt?

Regardless, I am much more concerned about implicit casts than explicit casts, as I expect the latter would end up just being dead weight for me, while the former has more potential to cause headaches. I see you saying that you "could" be convinced that implicit casting is a bad idea, implying you aren't convinced yet. What are your remaining reservations?

I'm not a big fan of having static methods attached to structs. For one thing, not having to deal with methods makes implementing and maintaining structs considerably simpler. For another, structs have to live inside a class, so you could always make the static method part of the surrounding class rather than the struct itself. It is a shame that GDScript doesn't have a way to create namespaces independent of class_name yet, but I think that problem is orthogonal to structs.

I'd been under the mistaken impression that it would be possible to define struct names which would be globally accessible. That's an unfortunate limitation, but as long as it remains in place, I agree with you that being able to access static functions using struct's name isn't particularly beneficial. NamedIntUtils.NamedInt.init() doesn't look any better to me than NamedIntUtils.init(). Ironically, if we did have true namespaces, I would feel that the ability to access static functions through a struct name was much more valuable. I'd be interested to hear what other people think, but in my opinion, NamedInt.init() > NamedIntUtils.init() > NamedInt(name = "Default", value = 7) > NamedIntUtils.NamedInt.init().

Also, my original post butchered the WebEvent tagged union example so badly that I'm not sure the intent was clear (I've fixed it). I especially want to point out that part of what makes it look readable and familiar without relying on any special syntax rules, beyond the general purpose sum type, is the use of nested struct definitions. NamedInt.init() is only slightly clearer than NamedIntUtils.init(), but in my opinion, if web_event.event_type is WebEventUtils.PageLoad is a substantial improvement over if web_event.event_type is WebEventUtils.PageLoad. I suspect that this clarity is partly true because WebEvent.PageLoad clarifies that PageLoad is owned by WebEvent while WebEventUtils.PageLoad just seems to suggest that PageLoad has something to do with WebEvents. It also looks more like Rust, which is where I'm guessing most people's preconceptions about tagged unions come from. Of course, "without special syntax rules" assumed that structs would have faux-namespaces similar to classes, which is clearly neither the case nor particularly valuable at the moment. Even so, I hope the option to declare helper functions, other stucts, etc. will be left open as an eventual possibility.

[nlupugla]

For explicit casting, I'll grant that it's a feature that's much harder to take away once it's added than add when it doesn't yet exist, so for that reason alone I'm inclined to agree with you that explicit casting shouldn't ship "at launch" so to speak. If users end up complaining about having to write a bunch of boilerplate to convert one struct to another, maybe that will be a cause to revisit. It's also easier for me, because it's one less feature I have to implement :)

For implicit casting my main reasons I haven't completely decided are a) I generally like to hear arguments from different points of view before committing and b) implicit upcasts and permutation casts would be expected in a structural type system. While I think that structs should lean more towards nominal than structural, I do think it's important to consider what most users will expect to "just work" given other languages they might have worked with or just common sense.

On the other hand, when you start bringing Traits into the mix, I kind of agree with you that the various casting features discussed so far become kind of obsolete and perhaps even detrimental. Plus, implicit casts are again a feature that's much harder to remove once it's been added. So I'd say I'm leaning pretty strongly towards shipping without any sort of built in casting, but I'd be interested to hear any arguments that go the opposite direction.

[eimfach]

I would not do any casting on them, that's what classes are for I would think. Classes provide more features but Structs are meant to be simple and to have a reference to a set of different types of data.

[idbrii]

From the issue: #7329 (comment)

I think dictionary initialization syntax could be re-used for structs (JSON, but with no forcing of quotes around field names). Then the keyword struct would make the interpreter distinguish between the two.

Benefit: can switch between the two at will. I think it's more important that optimization is achieved with the user just adding the word struct instead of rewriting stuff to a different syntax flavor.
That said, Struct is meant to supersede Dictionary in many places in the API, so there is certainly an argument to be made that the syntax should provide a smooth transition from Dictionary, not Resource like I mentioned.

[idbrii]

I think making a syntax that's similar but quite different from dictionary (var within {}) would be more confusing. A more literal version of what @starry-abyss said:

struct CharacterStats {
    hp = 100,
    mp = 100,
}

Then the inside of the {} is like a dictionary. However this relies on implicit typing which seems like a bad idea when declaring types to serialize or pass to native.

Also using the dictionary syntax implies that you have default values which isn't always the case.

Writing it like classes has the advantage of being familiar to most users.

[idbrii]

After more thought, I think @starry-abyss point about easily switching dictionary to struct is most relevant in creating instances of structs and not defining them.

We should focus this aspect of ease of use on how to we convert creating a dictionary to instantiating a struct.

Changing creating a dictionary:

var named_int := {
    name = "named_int",
    value = 3,
}
send_data(named_int)

To struct:

# definition only happens once
struct NamedInt:
    var name : String
    var value : int

var named_int := NamedInt(
    name = "named_int",
    value = 3,
)
send_data(named_int)
# or even closer
var named_int := NamedInt{
    name = "named_int",
    value = 3,
}
send_data(named_int)

[idbrii]

The latter creation example with {} only requires putting the name of the struct in front of the dictionary.

Despite having to change {} to () I think still prefer the former due to consistency with other languages. Would be nice if you could include a trailing comma in each line (python allows that).

[DDAN-17]

Can't you just make a new class?

[DDAN-17]

Except, Object is already light. I don’t see how it could be made lighter.

[AThousandShips]

Object is not light, they contain lots of stuff structs wouldn't:

• Methods
• Signals
• Scripts
• Other memory management details
• Extension data

[DDAN-17]

Then why does the third paragraph of https://docs.godotengine.org/en/latest/tutorials/best_practices/node_alternatives.html say that Object is “The ultimate lightweight object”?

[AThousandShips]

Because it is in comparison with Resource and Node, not with some hypothetical other data storage, obviously it isn't the most lightweight data storage container possible, just compared with the other options listed there

[DDAN-17]

Ohhh. Ok

[azur-wolve]

so there doesnt exist any room to a future possible lightweight data structure that lives in the memory stack? (due to Variant)
if so i would suggest to name this one which is by reference so lives in the memory heap to "Tuple"
and reserve the name "struct" for the aforementioned

[AThousandShips]

There's no way to put a dynamically defined data type in stack, and since this type is primarily intended for scripting anyway it won't be on stack anyway because memory is allocated on heap for memory in scripting

The name struct doesn't really imply anything about where it resides in memory, it's just "STRUCTured data"

[nlupugla]

Hi all, it's been a while since I've updated this discussion, but as my work on adding Structs to GDScript is nearly ready to review, I have encountered another essential question. I've updated my original post with this question as well for posterity.

Question 5. When (if ever) should casting between Structs and Arrays or Dictionaries be automatic?

Consider the following example.

struct NamedInt:
    var name : String
    var value : int


var named_int := NamedInt(name = "Godot", value = 4)

named_int = ["Godot", 5]                              # should Array to Struct be automatic?
named_int = {named = "Godot", value = 4} # should Dictionary to Struct be automatic?


var array := []

array = NamedInt(name = "Godot", value = 4) # should Struct to Array be automatic?


var dictionary := {}

dictionary = NamedInt(name = "Godot, value = 4) # should Struct to Dictionary be automatic?

Each of the cases above will certainly work if the user adds the appropriate explicit cast using as, but the question is if the casts should occur implicitly as well. I am inclined to say that these kinds of casts should never be implicit, but I can also see the appeal of being able to write the very concise named_int = ["Godot", 5] over the more verbose named_int = NamedInt(name = "Godot", value = 5) or named_int = ["Godot", 5] as NamedInt.

I'm interested to hear what you all think.

[eimfach]

Yeah I was thinking of that also. Still you would need to keep track of this. If you would find this (named_int = ["Godot", 5]) along the lines somewhere, what is it going to be ? A converted Struct or an Array ? StringName and String being so similar also syntax wise, it makes sense. I really don't see the benefit of ommiting the "as NamedInt" but rather potential misunderstandings and overhead along the lines. Especially if you didn't write the code yourself....

[nlupugla]

Another point to consider is how robust Structs should be to changing the order of their fields around. For example, if for some reason I decide I like it better if the "value" field comes before the "name" field, I might change my code from

struct NamedInt:
    name : String
    value : int

var named_int : NamedInt = ["Godot", 4]

to

struct NamedInt:
    value : int # new order
    name : String

var named_int : NamedInt = ["Godot", 4] # oops, forgot to change this line

Reordering the fields in a Struct might actually be fairly common, because the order they are defined will determine the order the fields show up in the inspector when they are exported and the order the elements will appear when the struct is printed to the console.

In the above example, there will be an analyzer error because the type of "Godot" i.e. String is not compatible with the type of value i.e. int. An even worse fate might occur if we swap the order of two members with the same type. Then the analyzer can't catch our mistake and we might end up accidentally assigning values to the wrong members. This pitfall would be avoided entirely if you were forced to use the more verbose NamedInt(name = "Godot", value = 4) syntax. That said, these same kinds of bugs can come up when you reorder the positional arguments of a function, and that pitfall is tolerated, so probably the same logic applies here.

[eimfach]

I think this is an excellent example, thank you. Also being explicit with the field names means, when changing the order of the field declaration it doesn't affect the order of the definition, which is a good thing. Existing definitions would still work, no refactoring needed. Right? (So the order of fields in the definition shouldn't matter -> named fields)

[DDAN-17]

Honestly, I can't see myself ever trying to convert from an Array to a Struct on purpose, so the cast shouldn't be implicit (or there should be a warning for it), but there should be an explicit way to cast between them.

[azur-wolve]

after reading all that, better to don't have implicit casts.
if want conversions have i.e. either Dictionary(struct) | Dictionary.to_struct() | @GlobalScope.dict_to_struct() and vice-versa.

GDScript doesn't have implicit conversions between Array and Dict, probably due the mentioned problems

the conversion between Struct and Array by only using the values looks problematic, bc if the order of the struct members change, the array should be updated.

The only solution i see is to pass 2 arrays, one with the names and one with the values, emulating a dict, but that still has the aforementioned problem.
Thats probably the reason why there's no constructor Dictionary(Array, Array)

Conversion with Dict is straightforward as dont need to care about order of elements, just of key-value pairs.

[AndrewAPrice]

Maybe make implicit casting trigger a breakpoint, but not crash. Or at least print an error in debug builds. If something slips through in a production release, it would be nice to avoid crashing the player's game.

…

On Mon, Oct 7, 2024, 7:09 PM nlupugla ***@***.***> wrote: I like the idea of having an "unsafe cast" warning. The reason I'm inclined against implicit casts is that I am imagining that if a user has gone through the effort of creating a struct, rather than a simple Array or Dictionary, that user probably cares about static typing enough that they wouldn't want their types to be sneakily stripped away. That said, I could easily imagine users that see things differently, so I'm happy to be persuaded in the other direction. — Reply to this email directly, view it on GitHub <#7903 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACHIV2XDKGUEMI6EH54HWDZ2MIB7AVCNFSM6AAAAAA5LGJJ46VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOBXGM3TCMA> . You are receiving this because you were mentioned.Message ID: <godotengine/godot-proposals/repo-discussions/7903/comments/10873710@ github.com>

[nlupugla]

I learned today that the ability to pass arguments by name in general is untenable due to some GDScript limitations #902. An argument could be made that an exception could be made for Struct constructors, but I think it's probably best to keep things consistent with the rest of the language.

So if constructing via NamedInt(name = "Godot", value = 4) is off the table, it begs the question of whether NamedInt("Godot", 4) should be an option or not. While this syntax would be consistent with other constructors in Godot (e.g. Vector2(0, 0)), I worry that it will give rise to hard-to-trackdown bugs when users decide to change the order that their struct members are declared for whatever reason, as detailed in my comment in the thread above. This potential pitfall is tolerated for user-defined classes, where reordering arguments of the constructor could cause similar bugs. However, one important difference is that the user must write the constructor for their class, whereas for structs the constructor is auto-generated based on the order the members are declared. At the moment, I am leaning towards allowing the NamedInt("Godot", 4) style constructor despite the potential pitfalls, but I am willing to be convinced otherwise.

Note you could always use a Dictionary if you wanted to assign values by name via NamedInt({name = "Godot", value = 4}), though this looks a little clumsy to me.

[eimfach]

Having two options would mean you can mix them, right (like in python) ? Or maybe people would ask for it ? Because that would introduce another layer of complexity having ordered arguments and non ordered arguments ... I also do not think it is the idea of a struct to support this.

If that'd be the case it's getting more and more just like a function (like in functional programming, there are also generated constructor functions for records, like in Elm: MyRecord arg1 arg2 arg3) but in fact we are just creating a struct. As with native constructors (Vector2 etc.) they look like GDScript functions and look like they can be used as those, but in fact cannot (Like using them as a Callable argument to a function for it to construct these types, you need a wrapper GDScript function). I find that a bit confusing personally.

Also a function itself by the name "NamedInt" to be used to create a a struct of that kind with partial arguments is out of the question then..

These aside, I would be happy with positional constructors also, just for the sake of having structs already :)

EDIT:
However NamedInt{name="",value=2} similar like in Go I would feel way more comfortable with. Even as a positional thing like NamedInt{"",2}. It does not look like a function and will not be treated by the user as those.

To cover also untyped scenarios you could put a keyword there:

var a = struct NamedInt{"",2}
var a:NamedInt = struct NamedInt{"",2}

or/and

struct a = NamedInt{"",2}
struct a:NamedInt = NamedInt{"",2}

(this would mean you could only reassign structs to "a" but any type of struct, maybe also it could be useful memory allocation wise ?)

Would that help ?

[dalexeev]

A constructor is essentially a function, I don't see the need for a distinction here. I would suggest that custom struct constructors have the same syntax as built-in type constructors (Vector2, Transform2D, etc).

Having two options (and even mixing them in a codebase) is not necessarily a bad thing. If your struct only has two fields, having to list their names every time can be annoying. If we add named arguments, it doesn't mean you stop using positional arguments everywhere.

[eimfach]

Think about it, in a context of structs we are not even talking about arguments but fields or members. But now we are mixing the meaning of arguments and fields/members (so far even that we are talking about named arguments in general GDScript functions). If I have a literal to create a struct, I am talking fields and I pass them with their names, like other non functional languages do and is shown also like this in the proposal (still looks like a function). Now you mix it up with function semantics it seems to me, saying a constructor is a function, - yes - but it is in a class context. Because it looks like a function, while it is not really (not a first class function - producing non Object derived data)

I agree that it might be annoying for some one. But are you not doing a similar thing with Dictionaries ? And is it annoying ?

[dalexeev]

I think we've gotten to the sophistical side of things. But can't your reasoning apply to built-in classes? Say Vector2 has fields x and y. Should you write Vector2(x = 1, y = 2) instead of Vector2(1, 2)? Or do you allow for a struct to have a canonical order of fields (and the order of the constructor arguments matches it)?

Dictionaries are different in that they are universal and allow any set of keys in any order. You just can't add something to a dictionary without a key. Whereas a struct is a fixed set of fields in a specific order. I think custom structs can also have a small set of fields that have a natural order. Just like built-in Vector2, Vector3, Color, etc.

[eimfach]

Dictionaries are different in that they are universal and allow any set of keys in any order.

Pragmatically spoken, Dictionaries are similar in the the way you would define them as a literal, is what I meant:
Like

# Dictionary
{ x = 1.0, y = 1.0} # I see Dict
# Struct
Vector2{x = 1.0, y = 1.0} # I see Struct, but also I see Dict

These look similar and they are in the way you would use them. They are structured data. The difference is what you described, so they are also different in the way you access them and how you extend them (besides the struct being a type of its own, and technically under the hood different but that's not the point).

Does the following look similar and are they semantically similiar ... not really ?

# Dictionary
{ x = 1.0, y = 1.0} # I see Dict
Vector2(1.0, 1.0) # I see Function

Is this Vector2{x = 1.0, y = 1.0} really annoying ? I don't think so. But I agree, Vector2(1.0, 2.0) is comfortable of course. Still I could have my own function for this comfort, right ? I am just thinking small and subtle distinctions are a good thing in syntax but not overdo it. Pragmatically spoken: This looks like a function, this should behave like any other function. I see Vector3, I think function ! I see struct, I want to think struct, but I think function !

I think the given native or built-in functions that produce structured data are a quirk and should look different maybe, but they are now there to stay, right ? Now this leading to the thought which arises that structs definitions should be consistent with them meaning they should be a function, not a literal, right ? Not sure I understand why.

Or do you allow for a struct to have a canonical order of fields (and the order of the constructor arguments matches it)?

Go-Lang does allow this:

type person struct {
	age  int
	name string
}
person{"Bob", 20}
person{name: "Alice", age: 30}

Having the fields with names and without. Of course I agree this is nice and would mean order matters, right ? I'd say let's just go the Go (and go :P) way also with the syntax (the curly brackets), forgetting whatever the quirky native functions do :P It would not look like a function nor be one, no one would think "oh, function" and it would be a literal also, named arguments being off the table for good (it's not a function) and everything is fine. This approach avoids any confusion with function calls and makes it clear that you’re working with structured data.

Maybe one day the native functions fade but we would still be stuck with our non-literal function structs...

P.S.: Struct literals survive nuclear fallout :P

[ShalokShalom]

@nlupugla I would like to see the code for this implementation.

You said its ready for review?

[nlupugla]

Sure! This is the pr: godotengine/godot#82198. However, the GDScript team has moved away from the implementation in that PR based on hacking structs into Array. As such I haven't worked on that PR for a while now, but I'm still involved in discussing the implementation and the discussion in this thread about the user-facing side of structs is as relevant as ever.

[IphStich]

I am working on a newer implementations of structs (PR) so I wanted to check in here and see if I understand the outcomes of the discussion, and also check if the conclusions are still valid, and that I understand them.

To help focus discussion, I want to split this into 2 different comments. The first is regarding syntax, and the second is regarding behaviour. I also have my own thoughts on each, and I will post those in replies.

---

Basic Struct Type Declaration

# Basic struct type declaration
struct NamedIntExtra:
	var name : String
	var value : int
	var extra : int

I don't think there are any disagreements about the above syntax

Only thing I want to note is that the specific implementation I am working on benefits strongly from statically typed (non-Variant properties). As a result, I would want to encourage people to not use Variant in their projects, or at least discourage it by forcing them to statically type to Variant if/when that was their intention.

Printing

Not a whole lot has been said here. I think this isn't super important to people.

Best case appears to have been made for NamedInt(name = "Godot", value = 4) and there doesn't appear to have been any disagreement. I don't think it is important to people, so long as it shows clearly the struct-type, the names of the properties, and the values of those properties.

Documentation

Options presented by OP were:
a) NamedInt
b) Struct[String, int]
c) Array{String, int}
d) [name : String, value : int]

I think the only real votes were for A. But I imagine this is similar to printing where it isn't a significant issue, so long as the information is available and easy to access and parse.

Construction

There seems to be a lot of disagreement about the specific syntax when it comes to construction of structs.

var named_int := NamedInt(name = "Godot", value = 4) # confusing, hard to distinguish from a function call, not feasible without big changes
var named_int := NamedInt("Godot", 4) # even more confusing, creates problems if names changed order

var named_int := NamedInt<name = "Godot", value = 4> # doesn't look good, doesn't follow any standards or expectations

var named_int := NamedInt{name = "Godot", value = 4} # potentially confused with dict, but otherwise clear, and allows for easy substitution into existing projects
var named_int:NamedInt = {name = "Godot", value = 4} # however, what would be the *expected* and *actual* behaviour here?
var named_int:NamedInt = function_that_returns_a_dictionary() # or here?

var named_int: NamedInt = [name = "Godot", value = 4] # definitely confusing, and nothing to distinguish it from valid array syntax so incompatible with ducktyping
var named_int: NamedInt = ["Godot", 4] # same problem, but potentially worse?
var some_var: Variant = function_that_returns_a_struct() # what would happen if I wrote some_var = ["Godot", 4] on the next line?

So it seems to me that any StructType() should be ruled out. More is said against than for it. I want to note as well that the suggested option of using a dictionary for construction like so: NamedInt({name = "Godot", value = 4}) is ambiguous in behaviour, as Dictionaries would be valid properties of structs it will be unknown which behaviour was intended (i.e. should it warn about assinging a Dictionary to a non-Dictionary property or expand it to properties of the struct? What if the first property was a Dictionary?).

I think most can agree that StructType{} syntax is in many ways the most useful, and clearest, but that it does introduce some slightly confusing syntax, and some hard-to-predict and slightly-unintuitive behaviours (in regards to how structs interact with Dictionaries).

Much has been said on [] syntax. A lot of back and forth it looks like. I think that, in practice, this wouldn't actually work as it would rely on some conversion between array and struct which would make it fundamentally incompatible with ducktyping. As in, the compiler would either have to know that the specified type is a struct ahead of time (incompatible with ducktyping and Variant), or we would have to allow for a way to update the values of a struct using an arary, which would introduce countless other problems. And a large part of this is because [x = y] is absolutely valid array syntax, that is there is no way for the compiler to distinguish "create a struct with property x equal to value y" from "assign the value of y to x, then create an array containing only x". So I want to safely rule this syntax out.

It does seem to me that construction is where most of the disagreements lie in regards to structs, and there is no consensus or agreements here.

[IphStich]

RE: Construction

Based on the discussion so far, it seems likely to me that StructType{} is the best solution, so long as we can answer the Dictionary problems. Which would likely mean requiring that the type is always paired with the {}. However, much like [], it does introduce some problems with ducktyping, in that the compiler would need to explicitly know ahead-of-time that the type is a struct. Which is incompatible with Godot's current implementation of duck-typing, and very specifically would mean that you cannot safely create new instances of structs that are not declared within either the engine or the current script. Either that, or we would have to introduce an entirely new behaviour associated with {} syntax (of which I have something more to say below).

On StructType() construction

Could work by explicitly declaring property order through the struct declaration. For example:

struct NamedIntExtra (name, value, extra):
	var name : String
	var value : int
	var extra : int

What this would actually do is create a struct-type called NamedIntExtra, and also a function called NamedIntExtra(). This would remain compatible with ducktyping systems, and resolve the issue of changing property order (as the actual order will always be defined here, similar to a constructor). Not having constructors creates this problem, and so pseudo-constructors could solve this problem.

On StructType[] syntax

I have an idea on how this could be workable. And that is by defining a new syntax and behaviour that hasn't been raised in this discussion: [X: Y, U: V].

var other_struct := NamedIntExtra[name: "A", value: 1, extra: 2]

# above would get compiled into something like below:
var other_struct: NamedIntExtra # if structs are val-type, then declaration is the same as initialisation
#var other_struct := NamedIntExtra() # this is also identical, or would be required if they are ref-type
other_struct.name = "A"
other_struct.value = 1
other_struct.extra = 2

I call the [X:Y] syntax a [property macro]. What happens is that when compiled, it will expand into multiple operations. And if preceeded by a type (or used when declaring a variable), will instanciate it and apply those properties to it. Effectively it is performing a series of set_named calls here.

A bonus of implementing this syntax would be that we can expland the logic to a pattern and apply it in cases of binary operations. As an example:

var other_struct := NamedIntExtra[name: "A", value: 1, extra: 2]

if my_struct == [name: "A", value: 1]:
    pass

# above would get compiled to:
if my_struct.name == "A" and my_struct.value == 1:
    pass

Which would also give uses a way to compare or check or set multiple properties of anything (not just structs) in a way that is really compact and distinct from any other language. It can also be made fairly clear through syntax highlighting to distinguish the names from the values.

The compiler and analyser should be able to distinguish this syntax from a valid array declaration by forward-checking for the : symbol (similar to how it can distinguish {=} and {:} dictionaries). This should make it fully compatible with ducktyping while quietly adding a brand new feature.

Interestingly, if implemented, this syntax would allow for some interesting behaviour.

var x: Vector3 = [x: 23] # Creates a new Vector3 with X=23, Y=0, Z=0
var y: Vector3 = x = [z: 4] # This would update x.z =4, then assign x to y

On StructType{} syntax

I do like the idea of allowing explicit StructType{} syntax (for struct construction) as this would let users more easily drop structs into their project (where they might currently be using dictionaries). However, this has potential implications on behaviour expectations (i.e. whether structs are reference-type or value-type) so might have to consider that too.

I think in many ways this would operate like the above [property macro], except it would only be allowable in explicit circumstances where it is unambiguous (by explicitly declaring the type out front).

var named_int := NamedInt{value = 4} # only context this would make sense in
var named_int: NamedInt = {value = 4} # invalid, you are declaring a struct and assigning it a dictionary

var my_struct := NamedInt()
my_struct = {value = 4} # invalid, you are assigning a dictionary to a struct value
my_struct = NamedInt{value = 4} # valid, as you are replacing my_struct with a new struct instance

var other_struct := NamedInt[name: "XYZ"] # valid, you are creating a new struct and assining "XYZ" to the name
other_struct = [value: 4, extra: 10] # valid, as this gets compiled to other_struct.value = 4; other_struct.extra = 10
var last_struct: NamedInt = [value: 10] # (potentially) valid because there is no other possible reading of this line

func my_func():
    return [value: 10] # invalid as you cannot return an operation
func my_other_function() -> NamedInt:
    return [value: 10] # (potentially) valid because there is no other possible reading of this line
func function_3():
    return NamedInt{name = "ABC"} # unambiguous, returns a struct
func function_4() -> NamedInt:
    return {name = "ABC"} # does this create an error? it definitely creates confusion as you need to know the return type to understand this isn't a dictionary

Potentially as well, {} could introduce similar behaviour as defined above. That is, if not paired with an operator, assumed to apply values to the previous identifier. So something like the below...

var other_struct := NamedIntExtra()
#other_struct{name = "A", value = 1, extra = 2}
other_struct{
    name = "A",
    value = 1,
    extra = 2,
}

# above would get compiled into something like below:
var other_struct: NamedIntExtra = NamedIntExtra()
other_struct.name = "A"
other_struct.value = 1
other_struct.extra = 2

Which would actually have some interesting connotations and use-cases? As what it would become an implicit .member operator for the idenfiers that follow...

Anonymous Structs Idea

I strongly like the idea of anonymous structs, as this way users don't have to explicitly type all their structs, meaning things can be compact and straightforward.

For this, I would like to start off by presenting a proposal for a compact way of defining structs.

struct MyStruct {x:int = 2, z := "X"}

# Gets functionally expanded to:
struct MyStruct:
    var x: int = 2
    var z: String = "X"

The syntax is perhaps a little similar to dictionaries, but the use of the struct keyword makes it unambiguous for the compiler. And hopefully the use of both : = as well as the lack of any apparant variable being assigned to, should make it clear that this is not a dictionary, making it easy to read.

So, for anonymous structs, I present the following proposal:

var my_struct := Struct{x:int = 2, z := "X"}

Once instanciated, uses would be able to add or remove properties, nor change the order of the properties or the types or names of the properties.

[IphStich]

What follows is about the behaviour of structs.

Reference-type vs Value-type

I haven't seen much discussion on this here, but it has been somehat in other locations. It seems to me that most people here presume structs are reference-typed? I do think that this question is important, as it impacts and relates to the aspects described below, so I would like anybody who responds to any of the below questions to have considered this in their response.

(To be clear on definition here, a reference-type would behave like an Array or a Dictionary, and value-type would behave like a String)

Equality Comparison

If we presume that structs are reference-type, then the result of an == should definitely be true if A and B refer to the same location in memory. That is, they use object/reference equality. I don't think there is argument here (except for whether structs should even be ref-type).

If we presume that structs are value-type, then the result of an == should definitely be true if A and B are of the same type and have the values. Again, I don't think there is argument here (except for whether structs should even be val-type).

I think the above are safe assumptions, and nobody has argued against either. So the questions that therefore remain are:

• (If structs are ref-type) Should A == B ever be true if they refer to different locations in memory?
• (In presuming "yes", or if structs are val-type) Should A == B ever be true if A and B are defined as different struct-types, but have the same properties with the same names and types in the same order?
• (In presuming "yes") Should A == B ever be true if A and B are defined as different types, but have the same properties with the same names and types in a different order?
• What about if one has additional names, or the types are different?

I don't think anyone has made a compelling case for "yes" on that last one.

Opinions are very mixed on the first. It seems to me that the answer depends on how much structs are viewed as "extra lightweight objects", or as "sets of values". So might be we need to think on that and decide on a philosphy, and an answer on whether they are ref-type or val-type?

The only compelling reason I have seen that should allow for a "yes" for any question after the first is to allow for comparisons, and to allow for something like polymorphism between structs (without needing inheritance). Therefore, these are only questions if we presume that either: structs are ref-type and castable between types with polymorphism like objects, OR structs are val-type and cannot be cast to another struct-type. Which again comes down to a question of philosophy, but now also of cast behaviour.

Casting Between Non-Struct Types

The consensus here appears to be that this shouldn't be possible. Neither implicitly, nor explicitly.

Where desirable to be allowed, it should be performed by calls to functions that explicitly create new values (e.g. struct_to_dict).

Casting Between Struct Types

A case has been made to allow for specific casts under specific circumstances, with varying degrees of error behaviour. Seems there has been little disagreement here, and I suspect that is related to the complexity of this, and the pending question of whether structs should be ref-type or val-type.

[IphStich]

I think a lot of the question of behaviour can be simplified if we first make some assumptions, then focus on some key questions.

First, let's assume that the system has an in-built function for converting between a struct of a type, to a struct of a different type, and in that process to copy over the values of any properties shared by both types.

Second, let's assume that the system has an in-built function for checking whether a given struct of an unknown type has all the properties (matching type and name, but not order) of a known type of struct. Presume also that using this function would give code completion for the known type.

Third, let's assume that any variable that is typed to a struct could also be empty (not contain any data, similar to null), and that this would not be an error, and would only trigger an error if a property was attempted to get/set from it. (For structs to replace API functions this would be a requirement due to how the API behaves)

Let's also consider this from the 2 separate perspectives of ref-type and val-type structs.

---

Here are my thoughts:

Situation: implicit casting when calling a function using a struct as a paramater

If structs were ref-type, you might want to treat them as polymorphic like with objects, and hand them off to functions which then may alter the structs, and you would want to retain that reference, so the function should be able to accept it without issue, so long as it meets the requirements, right?

Like, if you were writing a function, and you typed the paramater as being of a particular struct time, then you wouldn't really care what the caller does, so long as you know it has the properties you need, and that all you need to do is check if it is empty or not. After all, it's not your fault if the user sent you a gangster when you wanted a baker, after all both are humans and both have the 1 property you care about: makes_x_dough_per_day.

On the other hand, if structs were val-type, then this flips entirely I think. Because if structs are val-type, then this question of polymorphism kinda disappears in these cases. It would be nonsense to pass something to a baker to the mob_boss function even tho they both make dough. So in such cases, we force users to have to convert the data. Now, should this conversion be implicit? I don't think so! Explicit? Maybe yes, maybe no. If not explicit, then through a construction or the in-built function at least (if at all).

Situation: assigning a value to a statically typed variable

This one is probably the most considered situation here, and I imagineit's because it's the easiest to conceptualise. If you declare a variable within a function, and then assign it something else, well maybe it should or shouldn't error?

But really, if you consider that a variable could be typed to Variant, or to unknown Struct, then you're telling the compiler you don't care which type of struct it is. Then later, you can use another function to check it's type before performing the type-specific logic. The might be useful for example if you're trying to find a particular value form an array or something. This would work fine if stucts are ref-type, and if they're val-type then you would be likely to store an index or something as well. In either case, you're likely to check the type of the struct if only confirm your value was found before proceeding. Now, you could either use a var found: bool or something similar, then go thru the mess of setting and checking it. But why bother when you could just check the actual struct, and ensure code completion while you're at it!

But also, what if you just had a really long function. It's possible that types of varaibles might get lost to you throughout all that. If you accidentally assigned something to something you didn't mean to, and the analyzer could tell that the types didn't match, surely you would want to know about it ASAP, right?

So what should error? What should warn? What should happen silently?

Well, what would you want in those situations described?

How important is it to you that the value is what you have typed the struct to? How important do you think it is that it isn't something similar to it? How important and likely do you think it is that you, or someone, would make a mistake in all this?

To be honest, I don't know. But I can imagine myself and others using the wrong type of struct to give as a param to a function. Like maybe the result of some other function. If those structs could be implicitly cast somehow... surely that would create problems... So there sould at least be some explicit casting, and nothing silent!

Bottom line ?

What if we just simplified everything and treated structs as information only for the code editor? Like, their primary purpose is to create type security and give us code completion. After all, checking if a struct has the same literal type would be a very easy check, but trying to check properties and such to perform free-form casts up or down or all-around is getting more and more expensive and starting to defeat the purpose of even have structs in the first place... So what if we just didn't? And only threw an error if the code tried to access a property that doesn't exist? Or assign something in a way that didn't make sense?

I mean, maybe we would want to give warnings and such if somebody tries to feed a function a value it doesn't expect, or assign a variable to something they shouldn't. In which cases, let's just assume users know what they are doing, and let them effectively suppress the errors by writing as Struct or whatever, and only throw the error when it really matters! We will still get the error in the end if the data is invalid. And I mean, if it does have all the types and names expected, then does it really matter? I'm the one putting the gangster in the bakery, surely I know what I'm doing if I tell you I know I am! And isn't this all about trust :)

And then when we really want conversion between types of structs, like adding or removing properties and such, well we can just use functions to do that as necessary.

(TL;DR) Are you sure types don't matter?

Struct properties (in GDScript) are only ever going to be accessed by property-name (converted to StringName when scripts are compiled). So for the actual execution, it really doesn't matter if it is the correct type or not.

So that means that the real question is: what behavior do you want to see? What would help you develop better and make you feel more secure?

(The only time it would really matter is if you're giving them as a paramater to an API function that expects to handle an actual c++ struct; which yes, will be possible!)

[seocwen]

A few notes. I'd pefer if structs were not so verbose. Could we declare each property without having write "var":
struct NamedIntExtra (name, value, extra):
name : String
value : int
extra : int
I hate writing "var, and not having to do it is something nice about dictionaries. It feels like such boilerplate in a language without types, or without globals you need to override with locals.

Likewise, could the type just be used as:
var named_int := NamedInt{"Godot", 4}
One less place I'd have to fuss over getting all my names consistent would be appreciated. I understand that a function-like syntax is unpopular with people for some reason - I don't know why, I think constructors are fairly straightforward. If we end up using curly braces, fine, I'd still rather it just work as a constructor, with default arguments, or maybe you just pass null arguments, for fields you want to go to default, or you name the field only if it's out of order.

As for Reference-Type Versus Value-Type - I'd say Reference-Type. The fact that you can't pass-value types by reference, ever, like in C# say, is a real impediment for simple types in many common situations. Sometimes, you end up wrapping the thing in an Array just to use it that way, which is an awful hack. If it was a value type that could be passed by reference, that'd be ideal, but that's never going to happen.

[IphStich]

Structs vs Records

It seems to me that much of the community has need for both ref-type and val-type structs. And that there are signficicant problems with both approaches as a result. For example, structs are definitionally val-type objects in most languages, and so that is behaviour that people are likely to expect. However, if structs did not exhibit ref-type behaviour, then people would be forced to use hacky solutions to enable or facilitate it.

So, I had an idea... What if we introduced both using distinct keywords?

struct keyword

In place of where a user might write class they would write struct to say that they are declaring a new val-type data structure, instead of anything that extends from Object.

struct NamedIntExtra:
	var name : String
	var value : int
	var extra : int

Struct static type

Users can use the word Struct to statically type a variable to declare that it may hold the values of any val-type data structure, not caring about the structure. This may be useful for checking the specific type later, or for passing the value on to some other function.

func my_func(in_param: Struct):
    other_function(in_param)

func other_function(in_param: Struct):
    if in_param is NamedInt:
        do_something()

record keyword

In place of where a user might write class they would write record to say that they are declaring a new ref-type data structure, instead of anything that extends from Object.

record MyRecordType:
	var name : String
	var value : int
	var extra : int

Record static type

Users can use the word Record to statically type a variable to declare that it may hold the values of any ref-type data structure, not caring about the structure. This may be useful for checking the specific type later, or for passing the value on to some other function.

func my_func(in_param: Record):
    other_function(in_param)

func other_function(in_param: Record):
    if in_param is MyRecordType:
        do_something()

Casting

I was thinking that it would also make sense to allow for users to explicitly cast between ref-type and val-type where such behaviour is required. This should only be allowed using explicit casting, and should give an error for any implicit casting. I think it would make sense to use typed-container syntax (like with Array and Dictionary) here, eg Record[NamedInt].

struct NamedIntExtra:
	var name : String
	var value : int
	var extra : int

func my_func(named: Record[NamedIntExtra]):
    named.value += 20

func other_func(in_param: Struct[NamedIntExtra]): # this should give a warning
    <do some stuff>

func something_else():
    var n := NamedIntExtra() # (or however they are declared and constructed
    var x := n as Record[NamedIntExtra]
    my_func(x)
    n = x as NamedIntExtra # and if I want to actually perform any updates on the original value, I need to cast back, and assign to it

func some_stuff(x: Record):
    var y := x as Struct # no reason it shouldn't work this way too
func some_other_stuff(x: NamedInt):
   var y := x as Record # or like this either