Add support for nullable static types in GDScript

[aaronfranke]

Describe the project you are working on: This applies to many projects. This is an offshoot from #737, example use cases and other discussions are welcome.

Describe the problem or limitation you are having in your project:

Let's say you have a method that accepts a 2D position, which would look something like this:

func whatever(vec):

A problem with this is that there's no type safety, so the function could unexpectedly break if the passed-in value is not a Vector2. One option is to use static typing:

func whatever(vec: Vector2):

This works, and now it's not possible for users to, for example, pass in a Color or any other type that's invalid for this method. However, now you can't pass in null to mean N/A or similar.

Describe how this feature / enhancement will help you overcome this problem or limitation:

If GDScript's static typing system allowed specifying nullable types, we would be able to restrict the type to either a valid value or null. The presence of a valid value can then be detected simply by checking if it is not null, as non-null nullable typed values must be valid values.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

My suggestion is to simply allow this by adding a question mark after the type name, which is the same syntax used in C#, Kotlin, and TypeScript. User code could look something like this:

func whatever(vec: Vector2?):

Describe implementation detail for your proposal (in code), if possible:

Aside from the above, I don't have any specific ideas on how it would be implemented.

However, I will add that we could expand this idea for engine methods. Many parts of Godot accept a specific type or null to mean invalid or N/A, or return a specific type or null when there is nothing else to return. For example, Plane's intersect methods return a Vector3 if an intersection was found, or null if no intersection was found. Nullable static typing could essentially self-document such methods by showing that the return type is Vector3? instead of Vector3.

If this enhancement will not be used often, can it be worked around with a few lines of script?: The only option is to not use static typing if you need the variable to be nullable.

Is there a reason why this should be core and not an add-on in the asset library?: Yes, because it would be part of GDScript.

[Jummit]

You could pass in Vector2.ZERO and check for it, as you would need a check either way. This is also safer, as null "could be the biggest mistake in the history of computing".
I'm also kinda scared that the whole type system will get even more complex, which could scare away new users from gdscript. (I know the complex syntax of java scared me away)

[bojidar-bg]

Note that with nullable types we could require people to handle nulls explicitly, similar to how kotlin does it. So:

func whatever(v: Vector2?):
    print(v.x) # Warning or error: v could be null
    print(v?.x) # (if there is a null-checked dot operator) Prints null if v is null
    if v != null: print(v.x) # Does not print if v is null
    print(v.x if v != null else 42) # Prints 42 if v is null

[Xrayez]

Here's some current use cases of mine (if I understand the proposal correctly):

# Use custom RandomNumberGenerator, or the global one:
var ri = RNG.randi() if RNG != null else randi()

# Adjust impact sound volume by relative velocity
func _adjust_volume_to_velocity(velocity_override = null):
	var strength = max_strength
	if velocity_override:
		strength = velocity_override.length()
       # configure db ...

You could pass in Vector2.ZERO and check for it

The logic could fail exactly at Vector2.ZERO position if you depend on it here (for tile-based levels this could happen more often I believe):

var attach_pos = get_attach_point_position()
if attach_pos == null: # not attached to anything
	return linear_velocity

[Jummit]

The logic could fail exactly at Vector2.ZERO position if you depend on it here (for tile-based levels this could happen for often I believe):

I often use a getter (which returns a "safe" boolean) to check for stuff, for example:

if not is_attached(): # not attached to anything
	return linear_velocity

[aaronfranke]

You could pass in Vector2.ZERO

@Jummit See the discussion in godotengine/godot#32614 for why this doesn't work.

[Jummit]

You could pass in Vector2.ZERO

@Jummit See the discussion in godotengine/godot#32614 for why this doesn't work.

It works, just not everywhere.
Also, OP makes a good point:

A better result might be to return Vector3(float.NaN, float.NaN, float.NaN).

I'm not proposing to use this in core functions, but in personal projects this is a good way to avoid null.

[fab918]

It works, just not everywhere.

So it's not a good solution.

[from your link against the null value] For example, if a function returns a positive int number, then upon failure to calculate the desired return value, the function could return -1 instead of null to signify the error.

I'm not agreed with that, basically you return a valid value when you precisely want to warn that something failed. This approach lack of consistency (the value sometime will be -1, some time an empty string, etc.) and limited: what do you do when the function can return the whole range of an int?

As far I know, the cleanest solution for the return type case, it's to raise exceptions that must be handled by the region of the code that call the function. But error handling isn't available in GDScript and don't solve the case described by @aaronfranke

[from you link against the null value] which means that the compiler can't warn us about mistakes caused by null at compile time. Which in turn means that null exceptions will only be visible at runtime.

At least there is an error visible somewhere, if you return a valid value and forgot to handle it, there will be the worst case scenario for a bug: no hint.

I find this proposal essential in a typed environnement, especially for the type returned by a fonction, it also useful for parameters like @aaronfranke suggested, to keep all the logic of a function, inside it. The alternative being to do pre-checks before to call the function, and so have a part of the function's logic outside it.

Moreover, it becomes more important in conjunction of #173, where you will be able to force the typing, without this proposal, the solution for returning a "error/null" value from a fonction will be to disable the type system with the any keyword...

[fab918]

If we want to get rid of the null and have a safe/clean approach, I was thinking about the Optional object in Java (how java solved the null issue)

If we implemented something similar in a less verbose/python like way, that a very good solution I think:

whatever(Optional(vec)) # or whatever(Opt(vec))
whatever(Optional.EMPTY) # or whatever(Opt.EMPTY)

func whatever(vec: Vector2?):
   var result := vec.get() if vec.is_present else Vector2.INF

[aaronfranke]

@fab918 The only practical difference between your proposal and mine is that you're wrapping the value in an object and using methods and properties instead of using a nullable type. I'm generally opposed to wrapper objects and this just adds complexity to something that would likely be easier if we mimic the way other languages do it.

For a nullable type, I would remove .get() and replace .is_present with != null:

func whatever(vec: Vector2?):
   var result: Vector2 = vec if vec != null else Vector2.INF

[fab918]

@aaronfranke I'm fine with your proposal.

But if the problem with your solution for some , it's the usage of null as @Jummit has pointed out, because "it could be the biggest mistake in the history of computing". My proposal is an alternative that protects users from runtime error that a forgot null value can produce (more cleaner but more verbose).

Anyways, no matter the implementation, I think this feature is essential to fully embrace the typed GDScript, especially with #173

[Wavesonics]

The Kotlin style ?. Syntax is very nice to work with, but it does lead you down a rabbit hole of dealing with nulls that new people might find wired. ?.let {} in Kotlin, gaurd in Swift.

If you are going to do strict null typing as part of the type system that is.

That being said, I too think this proposal is essential for GDscript to be and to be used in larger projects.