GDScript: Better handling of void

[miv391]

According to the documentation about types there is no such type as void. Still, you can define void as a return type:

func typed() -> void:
	pass

When you assing this to a variable, the variable's value and type will be null.

var a = typed()
print(a) # prints null

If you instead define variable's type and try the same:

var a: int = typed()

then you get a runtime error "Trying to assing value type 'Nil' to a variable of type 'int'."

So what is the return type of that function actually? void, null or Nil? This is quite confusing, where did that Nil come from?

I propose that assigning void to anything should be an error. I cannot think of any case where assigning return value of void function to a variable would be useful. But allowing it will cause very likely bugs like this:

var arr1 = [1,2,3]
var arr2 = arr1.sort()

As sort returns void, arr2 will be null and I'm pretty sure that's not what the programmer expected.

According to the documentation about basic built-in types there actually is a type null, but it cannot be used as return type, so is it a type after all? This doesn't work:

func typed_null() -> null: # this will cause an error: Expected return type or "void" after "->".
    return null

I propose that void and null would be distinct types (as they are in e.g. Typescript). Example:

func int_or_null(a: int):  # return type will be either null or int
    if a % 2 == 0:
        return null
    return 1

func typed_void() -> void:  # return type is void
    pass

func typed_null() -> null:  # return type is null
    pass

var a = int_or_null(8)  # a's type is null and its value is null
var b = int_or_null(7)  # b's type is int and its value is 1
var c = typed_void()    # this would be an error, because assigning void is not allowed
var d = typed_null()    # d's type is null and its value is null

I'm not sure if there are any use cases for returning typed nulls. But if null is an actual type, maybe it should be allowed to be a return type.

[Calinou]

Related to #162, which I believe is a more robust solution to this problem compared to having an actual null return type.

[miv391]

That proposal uses question mark for nullable types, like this:

func int_or_null(a: int) -> int?:
    if a % 2 == 0:
        return null
    return 1

Typescripty way, which requires the actual null type, would be:

func int_or_null(a: int) -> int | null:
    if a % 2 == 0:
        return null
    return 1

I like how Typescript handles types as it allows also other options than just "some type or null", so this is not just a syntactical difference. For example:

func int_or_float_or_null(a: int) -> int | float | null:
    if a % 3 == 0:
        return 1
    elif a % 3 == 1:
        return 3.14
    return null

[Calinou]

See #737 which also proposed adding union types to GDScript. While union types are more powerful than nullable types, they're also more complex to implement and maintain.

[miv391]

Either nullables or union types would be a nice addition to GDScript, but my proposal is about fixing the confusing null / void type. I think those should be defined better and fixed before starting to work with nullables or union types. I think that experienced programmers can manage with how null and void currently work, because nulls are quirky in many programming languages and the vocabulary is more or less familiar. But new programmers, to whom GDScript is first or maybe second programming language, the way null and void work may be an obstacle for using static typing at all as it can cause subtle bugs and mysterious error messages about Nils.

Currently there are no separate null and void types. void just seems to be the type name and null is the only value for it. The quick fix would be just to rename void to null, so that both type name is null and it's only value is null. I think everything would work just fine after that.

However, then it would be obvious that separate void type is needed too. For example, let's look at Array's sort method. Currently it returns void and it seems to be a good return value as the method doesn't want to return anything (I think it would be better to return Array itself, but let's ignore that now). But currently the returned value is not "nothing", it is null. If the proposed void to null rename were made, it would be very obvious that now there is something very wrong about sort returning null. Why on earth would the sort method return null? Currently the naming just hides the embarrassing fact that null is returned. So a "new" void type would be needed and the sort method's return type should be that "new" void which really is nothing and that nothing cannot be assigned to anything. That would prevent bugs like this:

var arr2 = arr1.sort()