Add enums to GDScript

[bojidar-bg]

TL;DR

I would like to avoid writing

const CORNER_W  = 0
const CORNER_NW = 1
const CORNER_NE = 2
const CORNER_E  = 3
const CORNER_SE = 4
const CORNER_SW = 5

And be able to write it like:

enum {CORNER_W, CORNER_NW, CORNER_NE, CORNER_E, CORNER_SE, CORNER_SW}

---

Some more ideas

Those ideas might simplify the usual workflow, or add additional features for strange workflows or setups.

Nice addition to avoid repetition:

enum CORNER_{W, NW, NE, E, SE, SW}

Custom values idea 1:

enum {CORNER_W = 1, CORNER_NW = 2, CORNER_NE = 3, CORNER_E = 4, CORNER_SE = 5, CORNER_SW = 6}
enum {CORNER_W = 4, CORNER_NW, CORNER_NE, CORNER_E, CORNER_SE, CORNER_SW}

Custom values idea 2:

enum {CORNER_W, CORNER_NW, CORNER_NE, CORNER_E, CORNER_SE, CORNER_SW} = [1,2,3,4,5,6]
enum {CORNER_W, CORNER_NW, CORNER_NE, CORNER_E, CORNER_SE, CORNER_SW} = range(1,7)

Maybe enum should be prefixed by const or var depending on use? (IMO, it would be better to assume const, as to not create ambiguities, and/or hard to understand code)

const enum {…}
var enum {…}

[akien-mga]

The wanted behaviour can be somewhat achieved with:

 const CORNER = { "W":0, "NW":1, "NE":2, "E":3, "SE":4, "SW":5 }

It's less elegant of course (and the variables would be CORNER.W and not CORNER_W) :)

Regarding the custom values ideas, it just boils down to supporting multiple assignments:

const CORNER_W, CORNER_NW, CORNER_NE, CORNER_E, CORNER_SE, CORNER_SW = 1, 2, 3, 4, 5, 6

[WeAthFoLD]

+1 Would really love to use enums.

But I don't think "var" enums are really helpful. (I think you mean "var" by being able to reassign enum values like CORNER_W = 5, correct? >.<). Do you have any use case in mind?

[bojidar-bg]

@WeAthFoLD ~ No, I don't have any use case in mind about them. Just added them as an option… 😄

[WeAthFoLD]

IMO enumerations are constants by nature, which is true in many other languages. If you allow enums to be variable and regard them as sth like syntax sugar of multiple assignments, they will be somewhat misleading >_

[Zylann]

What about naming the enum, so we can write Corner.NW ?

[neikeq]

@Zylann I don't see the point since GDScript is dinamically typed. But if the above is implemented, you could do something like this:

class Corner:
    enum { W, NW, NE, E, SE, SW }

[Zylann]

You could use named enums to put them into exported variables, so we can reuse their values, type them or document them without rewriting.

[Sslaxx]

So, is Corner.W the syntax to be used for accessing enums?

[bojidar-bg]

@Sslaxx Well, yeah, depending on what you want from it. All three of those are valid:

#1
enum Tile {EMPTY, WALL, BREAKABLE, ONEWAY}
func foo(bar):
    if bar == Tile.EMPTY:
        return true
    return false # TODO, make it possible to go through oneway tiles

#2
func _bar(foo):
    return foo == EMPTY # Not that namespaced, but, well...

#3
enum {STATUS_ERROR, STATUS_GOOD, STATUS_EVER_BETTER}
func prune_connections():
    for conn in connections:
        if connections[conn].status == STATUS_ERROR:
            connections.erase(conn)

[Zylann]

The point I see in "namespacing" is actually being able to name the enum, so it could be used in export for example (instead of writing all possible values twice), or documented.

[bojidar-bg]

@Zylann Yeah, that's planned, though it would be nice if you open an issue about it 😄