Should the Error enum even exist?

[Niriel]

TL;DR

I feel like there may be a little cleaning up to do. Maybe it's just a matter of documentation.

We have an Error enum, but nothing uses it yet. Functions that semantically could return an Error still return an int instead. For example, signal.connect could return Error instead of int.

It's not a big deal, but to me it feels messy. It also misses some advantages of strongly-typing in GdScript.

The long, overly detailed, explanation

The global scope contains an enum Error that lists 49 of error-code names and their corresponding integer value. For some reason, all that information is duplicated in the global scope: there are also 49 integer global-scope constants with the same values.

Good strongly-typed code

Look at this code. It is perfectly typed. No complains from the parser, no warning upon execution. Using Error makes the intent clear and the code is self-documenting.

func ready() -> void:
    var err: Error
    err = generate_error()
    assert(err == Error.ERR_INVALID_PARAMETER)  # That is good.
    assert(err == ERR_INVALID_PARAMETER)  # That is a bit weird but ok...
    print(err)  # breakpoint here

func generate_error() -> Error:
    return Error.ERR_INVALID_PARAMETER

Of course, in the end, we know it's all int. Place a breakpoint on the print line, and you'll see err in the local displayed as an int. Fine. Error isn't real, it's a type-checking tool that helps the developers.

Weird code that GdScript forces us to write

Now, look at this code. This raises a warning during execution.

signal pause_changed(new_paused: bool);

func _ready() -> void:
	var err: Error
	err = pause_changed.connect(on_pause_changed) # WARNING during exec
	assert(err == Error.OK)  # Clean.
	assert(err == OK)  # Weird, why is OK also top-level const?
        print(err)  # breakpoint here

func on_pause_changed(new_paused: bool) -> void:
    print(new_paused)

We get the following warning when we hit err = pause_changed.connect():

W Integer used when an enum value is expected. If this is intended cast the integer to the enum type..

This makes sense because signal.connect returns an int. But from the documentation, we can clearly see that the possible return values are part of the Error enum.

This code must be changed to:

func _ready() -> void:
	var err: int
	err = pause_changed.connect(on_pause_changed)
	assert(err == Error.OK)  # In this case, THIS is the WEIRD thing.
	assert(err == OK) # Integer errors, we're coding in C.
        print(err)  # breakpoint here

Which entirely defeats the point of Error existing. Why does the Error enum even exist when built-in functions and methods don't use it?

Suggestion

It feels like a dev in the past started to move from int to Error but never finished the work. Either we continue that work, or we revert it.

• Either we make global-space functions and methods return Error, and we compare with the Error enum (if err == Error.ERR_INVALID_PARAMETER);
• Or we get rid of the Error enum, keep all the integer constants, and our functions return integer like in the old times.

[Niriel]

Actually, ConfigFile methods do return Error, so it is used. Just not everywhere.

[sockeye-d]

A lot of methods return an Error type, especially those that handle parsing text and file system stuff. And yes, it is an int internally, but all enums are and they're a rather thin abstraction to begin with.