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