Godot: GDScript enums override constants.

Created on 22 Nov 2017  路  11Comments  路  Source: godotengine/godot

I'm using Windows version of 2.1.

The problem I ran into is that enums using the same names as constants will replace their value.

Such as:

const NUMBER = 100

enum INT { NUMBER = 2 }

func _ready():
    print(NUMBER) # Shows 2
bug gdscript

Most helpful comment

Yeah, I tagged "bug" because it's a bug that it allows this shadowing instead of erroring out.

All 11 comments

I haven't tested but it's likely the same in master too, so should be fixed for both. cc @bojidar-bg

AFAIK, this is expected. It's similar to C++ enums. It should error because NUMBER is already declared though.

Yeah, I tagged "bug" because it's a bug that it allows this shadowing instead of erroring out.

Related to #6221.

Per https://github.com/godotengine/godot/issues/6221#issuecomment-320932451 @reduz intends (intended?) to leave this issue for 3.1.

I think we should add some way to mark enums as "to-be-kept-as-dictionary-only". Some examples to explain it:

enum {INT = 1, STRING}
# equivalent to:
const INT = 1; const STRING = 2

# ---

enum Type {INT = 1, STRING}
# equivalent to:
const INT = 1; const STRING = 2
const Type = {INT = 1, STRING = 2}

# ---

!enum Type {INT = 1, STRING} # some cool proposal here
# equivalent to:
const Type = {INT = 1, STRING = 2}

Now, the question is how to mark those enums, feel free to propose the syntax 馃槂 .

No, we don't need to add support for half shadowing. Just trigger a syntax error when an enum shadows a constant.

@bojidar-bg I don't get the point, if you need just a dictionary you can simply make one. There's no much gain in avoiding to set the values manually.

@bojidar-bg guess popular demand here just wants an error to be triggered :)

We have now entered release freeze for Godot 3.0 and want to focus only on release critical issues for that milestone. Therefore, we're moving this issue to the 3.1 milestone, though a fix may be made available for a 3.0.x maintenance release after it has been tested in the master branch during 3.1 development. If you consider that this issue is critical enough to warrant blocking the 3.0 release until fixed, please comment so that we can assess it more in-depth.

@vnen , @bojidar-bg what to do with this?

Was this page helpful?
0 / 5 - 0 ratings