Support covariant return types of overriding functions

[bitbrain]

Implements proposal godotengine/godot-proposals#7450

This pull request aims to implement covariant support for return types of overriding functions.

Bugsquad edit:

• Closes: Support covariant return types for overriding functions godot-proposals#7450

[anvilfolk]

I don't completely understand covariant types and am too sleepy to dig into it right now, but pressed review by mistake so here we are! 😅 I looked through the code and saw a couple of things that probably could use changing, so I marked them out.

Also, it feels like this logic ought to be applicable to more than function return types? Could the new GDScriptAnalyzer::is_super_type() function be used elsewhere? I feel like I've seen this code somewhere else, maybe in assignments?

I also have a question about what would happen with:
C extends B extends A, and A.greetings() -> BaseClass, B.greetings() -> SubClass but then C.greetings() -> BaseClass again. It should error because the return of C.greetings() is not the same or subclass of the return of B.greetings(), right?

[dalexeev]

I don't think we need the is_super_type() method at this point and in this form. This brings up the subtle question of the difference between type compatibility and type inclusion (implicit conversions, whether Nil is a subtype of Object, metatypes). Even if we add the method, it is actually useful in a relatively small number of cases (the is operator), in most cases we should still use is_type_compatible().

I will try to refactor is_type_compatible() so that it can be used in this PR.

[bitbrain]

I also have a question about what would happen with:
C extends B extends A, and A.greetings() -> BaseClass, B.greetings() -> SubClass but then C.greetings() -> BaseClass again. It should error because the return of C.greetings() is not the same or subclass of the return of B.greetings(), right?

@anvilfolk thank you - I have added this test case to verify that it fails correctly: https://github.com/godotengine/godot/pull/80457/files#diff-918b56d949925f87a6f93c202553fabea909d3287eaf34348d8d55df264c5b27R2

[adamscott]

Discussed during our GDScript team meeting. This feature would be great for the language and we think it should make it to the 4.2 release. Thanks @bitbrain !

[adamscott]

We should check if it works with the builtin types, just for safety mesures.

[vonagam]

I see a problem with current statement that checks for covariance:

!is_type_compatible(p_function->get_datatype(), parent_return_type, true) && 
is_type_compatible(parent_return_type, p_function->get_datatype())

Second line is obviously needed as it is a definition of covariance but first line looks hacky - it is there to filter out Variants, which I think should be done properly.

For example, if I understand correctly, current implementation will not allow to override a typed Variant return with a more specific one. But this should be valid covariance.

So need proper handling of Variant/weak types instead of reverse call to is_type_compatible and yeah more tests with built-ins, specifically Variants (explicit (hard ones) and implicit (weak ones)).

[dalexeev]

Also note that this PR implements return value covariance, but does not implement parameter contravariance. This doesn't have to be added in one release, but it makes more sense.

[dalexeev]

This check does not work correctly in some cases.

• See GDScript: Add return type covariance and parameter type contravariance #82477.

[YuriSizov]

Superseded by #82477. Thanks for your contribution nonetheless!