Use Block syntax for enums (GDScript 2.0)

[Shadowblitz16]

Describe the project you are working on

Just checking out gdscript 2.0

Describe the problem or limitation you are having in your project

Nothing

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Can we change the syntax of enums to use the correct block syntax?

enum MyEnum1:
    A
    B

enum MyEnum2:
    A = 0
    B = 1

instead of...

enum MyEnum1 {
   A,
   B
}

enum MyEnum2 {
   A = 0,
   B = 1
}

It's more consistent on how python uses classes for enums and is more consistent with the block syntax

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

See above

If this enhancement will not be used often, can it be worked around with a few lines of script?

It would be used all the time

Is there a reason why this should be core and not an add-on in the asset library?

• It improves readability
• It's easier to learn since other code blocks use it
• It's a good time to change it before godot 4.0 is released

[Mickeon]

I would propose it as an alternative syntax, not the standard. Enums in GDScript have the interesting property of behaving more akin to constant dictionaries. Something about the current syntax reinforces that notion.

[gustavi]

I found "alternative syntax" a really bad design for programming language. It make them hard to learn/read and make conflicts on "the good way" to do things between developers. Syntactic sugars are really cool (Python decorators for example) because they reduce the amount of code, they have a huge benefits. An alternative syntax that give no benefits except make some people happy because they prefer it is a bad thing.

[Spartan322]

I found "alternative syntax" a really bad design for programming language.

GDScript supports semi-colons as an "alternative syntax", so this is not unprecedented in the language.

It make them hard to learn/read and make conflicts on "the good way" to do things between developers. Syntactic sugars are really cool (Python decorators for example) because they reduce the amount of code, they have a huge benefits.

GDScript is not python, it should not try to emulate it continuously. It is not up to us to define a "good way" to do things, again its not python, we have no requirement to do one thing and that already isn't really done in the Godot at all. Also syntax sugar reducing code very slightly does not justify itself, and even then this is not a syntax sugar.

An alternative syntax that give no benefits except make some people happy because they prefer it is a bad thing.

Backwards compatibility, differential clarity, and syntax consistency. Python's enums are not GDScript's enums, by confusing them you are causing people to learn bad habits in the language that should not apply.

[KoBeWi]

Looks similar to #1878

[Calinou]

I don't think this alternative syntax brings any significant benefits compared to the existing syntax. The current syntax requires you to write a comma after every element, but this also allows you to list multiple elements on the same line if you wish.

If we adopt such a syntax, it should be the only syntax supported. However, it wouldn't support listing multiple elements on a single line (except with ; maybe).

[Shadowblitz16]

Looks similar to #1878

It is a basically the same, the only difference is I didn't realize dictionaries weren't enums back then.
This is one of the main reasons behind this suggestion. Also this version doesn't have that wacky : syntax which really doesn't make sense for a enum.

[dalexeev]

It's just a cosmetic improvement, but as I wrote, I don't mind it. Yes, it will not bring much benefit, but it will improve the appearance of the language.

However, it wouldn't support listing multiple elements on a single line

I don't think this is a big problem. Documentation comments for enumeration values also assume that each value is on a separate line.

Enums in GDScript have the interesting property of behaving more akin to constant dictionaries. Something about the current syntax reinforces that notion.

• An enum is a definition, not a value literal.
• Enums differ from constant dictionaries in that enums can be used in type declarations.
• You can't omit values in dictionary literals, but you can in enums.

GDScript is not python, it should not try to emulate it continuously.

Python's enums are not GDScript's enums, by confusing them you are causing people to learn bad habits in the language that should not apply.

Even if some things are different in different languages, this does not mean that they should look different. Having a different syntax just to avoid user confusion is not a very good motivation.

Backwards compatibility

Not sure. Any change is an additional barrier, but I think that in this case it is still worth it. GDScript has changed a lot in 4.0, including fixing old errors. For example, setget has been replaced with properties that also use block syntax.

differential clarity

See above.

syntax consistency

I vote for block syntax.

I found "alternative syntax" a really bad design for programming language.

If we adopt such a syntax, it should be the only syntax supported.

I agree, there should be only one option. (But sometimes an alternative syntax has the right to life, for example, we have two dictionary literal syntaxes: Python style and Lua style.)

[KoBeWi]

I don't think this is a big problem.

For some (most?) people this is a big problem. All of my enums are in single line. Line per enum value just clutters code unnecessarily.

[dalexeev]

All of my enums are in single line. Line per enum value just clutters code unnecessarily.

Before:

enum MyEnum {ONE, TWO, THREE}

After:

enum MyEnum: ONE; TWO; THREE

[me2beats]

Why not

enum MyEnum: ONE, TWO, THREE

unnamed:

enum ONE, TWO, THREE

[dalexeev]

Why not

enum MyEnum: ONE, TWO, THREE

I thought about it. But if this code

func f():
    x = 1
    y = 2
    z = 3

becomes

func f(): x = 1; y = 2; z = 3

then this

enum MyEnum:
    ONE
    TWO
    THREE

should become

enum MyEnum: ONE; TWO; THREE

I'm not sure if we should make an exception here and replace semicolons with commas.

enum ONE, TWO, THREE

There should be a colon here:

enum: ONE, TWO, THREE

or

enum: ONE; TWO; THREE

[Pigzinzspace]

{} first of all indicates that this is a set, the general designation of a set
this does not affect readability in any way, as it is only used when declaring

[Shadowblitz16]

@dalexeev I like the the ; one too. But the main idea is it would be consistent with other types of code blocks.
So whatever if, elif, else, class and the like use for multi line and single line code is what I think should happen with enums.
I haven't actually tried using multiple expressions with single line on other block types so it would have to be tested.

[Pigzinzspace]

@dalexeev I like the the , one too. But the main idea is it would be consistent with other types of code blocks. So whatever if, elif, else, class and the like use for multi line and single line code is what I think should happen with enums. I haven't actually tried using multiple expressions with single line on other block types so it would have to be tested.

there are brackets when declaring an array
there are brackets when declaring a dictionary
when declaring an enum, should they disappear?
it's just meaningless nonsense, which also brings senseless diversity, the same things should be done the same way! Variables should be declared the way most users expect it to be, not the way someone saw it in their fantasies.
It's not just meaningless, it's harmful.

[Mickeon]

It's why I was suggesting the optionality of it, but I understand the bigger complexities that'd bring to the table.
I just see current and suggested styles' arguments as making a fair bit of sense. Both look really nice. However, I would prefer using the ";" for splitting one-line Enum definitions as by this proposal.

[Shadowblitz16]

@Mickeon I fixed a typo in my message.
I think I would actually agree with @dalexeev that ; makes more sense.

[dalexeev]

Personally, I supported this proposal, but we did not have time to reach consensus before the 4.0 release. So the enum syntax change cannot be approved for 4.x for compatibility reasons anyway. We expect 4.x to be the main development branch for many years, so it makes little sense to plan this for 5.0 at the moment.

We also prefer not to have multiple syntax options doing the same thing. For example, we have two dictionary styles, but the Lua style allows you to omit quotes for keys. We have two setter/getter styles, but the alternative style allows you to use a separate function like setget in 3.x. An alternative enum syntax would not bring any bonuses other than aesthetic ones. I think it's not worth it, it would only complicate parser, clutter documentation, etc.

So I think it's reasonable to close this proposal for now. Thanks for the contribution nonetheless!

[Mickeon]

I think closing and archiving this proposal was not a good decision. It'll just be forgotten to time by the time development for 5.0 rolls around. There are a few proposal put on hold for 5.0 and I believe this should be one of them, especially given the discussions above. Marking proposals for 5.0 does not guarantee anything, but it gives plenty of time for further discussion to ramp up until it's time to make a final decision.

[dalexeev]

@Mickeon Okay, let's do it as you suggested, since there is interest in this proposal. But I think that this has little effect in the meantime, since 5.0 is still very far away. Then we will probably re-evaluate many proposals, including those rejected at the moment.