Add a keyword for abstract classes in GDScript

[aaronfranke]

Implements and closes godotengine/godot-proposals#5641

This PR adds a keyword for marking a script class as abstract in GDScript.

I tested multiple combinations of abstract and non-abstract inheritance and they all work. As an example, in this image MyAbstract is abstract, while the other is not. Note that if ExtendsMyAbstract was made abstract then both would be hidden.

abstract class_name MyAbstract extends Node

class_name ExtendsMyAbstract extends MyAbstract

And here's what happens if you try to instance with .new():

A previous version of the PR used @virtual, but the feedback has been overwhelming that abstract is better. After that, another previous version of this PR used an annotation @abstract, but it was discussed that a keyword is preferred.

Production edit: closes godotengine/godot-roadmap#66

[ryanabx]

Are abstract methods supported with this PR?

[aaronfranke]

@ryanabx No, only abstract classes are supported with this PR.

[dalexeev]

1. I think the @abstract annotation should be possible to apply not only to the top-level script, but also to inner classes. Applying the annotation to a script should not make inner classes abstract.
2. The check should be performed in release builds too.
3. Perhaps this should be keyword abstract (like static and potential public/private) rather than annotation @abstract, especially if we add the ability to declare methods abstract (must be implemented in a child class so that it can be non-abstract).

[adamscott]

Talked about in the current GDScript meeting. The PR should implement the elements 1 and 2 stated by @dalexeev. For number 3, we're still discussing this in the meeting, so no decision has been made.

[anvilfolk]

Yeah, my thoughts on 3. are whether it makes sense to (for this PR or eventually) have the "granularity" of abstractness exist at the class or at the method level. For example, with it at the method level:

class AbstractBecauseOfAbstractMethods:

func this_method_is_implemented():
    pass

@abstract
func this_method_is_virtual_slash_abstract()

func this_is_also_implemented():
    pass

# ----------------------

class StillAbstract extends AbstractBecauseOfAbstractMethods:

func some_new_implemented_func():
    pass

# ----------------------

class FinallyNotAbstractClass extends StillAbstract:

func this_method_is_virtual_slash_abstract():
    pass

We could force the users to annotate a class to be marked as abstract if any of its functions are still abstract.

This would give people more granularity in what precisely makes the class abstract. It doesn't make GDScript any more expressive, since you can always 1) tag a class as abstract, then 2) have methods implemented with assert(false) or pass, which would be functionally the same.

Folks agreed during the meeting that this wouldn't be a blocking thing for this PR, and that it could be implemented later :)

[aaronfranke]

I will get to work on 1. For 2, this is trivial because it's just removing #ifdef DEBUG_ENABLED. To be clear I don't mind it in release builds, I just wanted to exclude it for improved performance, but if it's desired then we can do that. For 3, I think an annotation makes more sense than a keyword.

[radiantgurl]

Have had this PR in my fork for over a month, had no issues with it.

[HolonProduction]

I don't think the name abstract is good, because it creates a confusion with native abstract classes which behave differently (e.g. can't be inherited), this will create confusion when talking about it or documenting stuff about it.

Could someone link me to the previous version were virtual was discarded?

[radiantgurl]

Looking good to me, havent had issues with this PR at all inside my own fork.

[dalexeev]

Overall looks good to me, but I guess such a feature needs to be approved at a GDScript team meeting, which hasn't happened in a long time.