GDScript Specification

[BWKC]

Introduction

This proposal advocates for the establishment and maintenance of a formal GDScript specification. Over time, GDScript has evolved and improved by introducing new features. Now is the moment to create a comprehensive specification that will not only streamline the development process, but also enable better tooling, documentation, and community collaboration.

Rationale for a Specification

A language specification is a document that delineates the syntax and semantics of a programming language. It acts as a blueprint for language designers, compiler developers, and other tooling creators. A well-structured specification brings numerous benefits, as detailed below:

Clear and Unambiguous Definition

A formal specification provides a single source of truth for the language's syntax and semantics, minimizing inconsistencies and ambiguities. This clarity supports improved communication among developers, tool creators, and users.

Alternative Implementations and Interoperability

A well-defined language specification allows for the creation of alternative GDScript implementations, including transpilers, interpreters, and JIT compilers for various platforms and use cases. Additionally, it enables the development of libraries and tools that interoperate with GDScript, such as bindings for other languages and platforms.

Expanding alternative implementations and interoperability broadens GDScript's reach and use cases, ensuring it meets the diverse needs of the game development community.

Enhanced Documentation

With a specification in place, documentation can be generated and updated more efficiently, granting the community access to accurate and current information, and fostering a better understanding and utilization of the language.

Streamlined Language Evolution

A specification simplifies the process of proposing and implementing new features as GDScript continues to grow and evolve. It offers a solid foundation on which to build, ensuring that changes align with the language's design principles.

Improved Tooling Support

Better tooling support, including text editors, linters, debuggers, and other development tools, becomes possible with a specification. Tool creators can more easily develop and maintain their tools with a clear understanding of the language's syntax and semantics, ultimately benefiting the Godot community.

Proposal Components

We propose the following steps to create and maintain the GDScript specification:

1. Develop an initial draft of the specification outlining GDScript's syntax and semantics, drawing from existing documentation and resources.
2. Solicit feedback from the Godot community, incorporating suggestions and revisions as necessary.
3. Establish a process for proposing and incorporating changes to the specification, ensuring it stays current and reflects the latest GDScript developments.
4. Create and maintain tooling that generates documentation from the specification, streamlining the process of updating and maintaining the official GDScript documentation.
5. Encourage the development of tools and resources that utilize the specification, promoting a more robust GDScript ecosystem.

Conclusion

A formal GDScript specification will lay a strong foundation for the language's future development, ensuring consistency, clarity, and a more vibrant ecosystem. By investing in a specification, we can unlock GDScript's full potential and enhance the Godot Engine experience for developers and users alike.

[Calinou]

There's already a GDScript grammar, but it needs to be updated for Godot 4.x. This is non-trivial as GDScript was rewritten from scratch in Godot 4.

Regarding having a formal language specification, GDScript isn't meant to be a standalone language you can use separately from Godot. It was designed for Godot's needs first and foremost.

Do you have a project that would require a specification? If so, please detail it here in a reply 🙂

[BWKC]

Basically any alternative implementations.

[AThousandShips]

What alternative implementations? Who would be writing one and why?

The language is fundamentally tied into the architecture of the engine, and doesn't make sense outside of it

Things like @onready and @export for example

[bvanevery]

Yeah I can't really see "reimplement Godot" as a goal, let alone a goal in Godot's best interest. "Fork Godot," that I could understand. But I think in that case you'd likely still have a relationship with Godot "upstream" of you, at least for awhile.

It's hard for me to believe that GDScript is so good that anyone wants to keep it for other things. GDScript in my case is one of the things that makes me not want to use Godot. Because I'm leery of tying my game development thought to a small language effort, that does not have an independently developed life of its own. For me, I'll be looking at the language plugin architecture again.

I think the more rational case for specifying Godot's language, is for people who are making a lot of content using GDScript. It's a versioning issue. When some new version of Godot comes out, does all my content blow up and stop working in the future? Am I left with piles and piles of stuff that I'd need to rework? Even small amounts of stuff that needs reworking, is a serious production burden for an indie game dev.

Specifications can help with locking down versioning. My relevant open source experience with that kind of issue, is with the CMake build scripting language. They take versioning pretty seriously, but they also have depreciation and end of support mechanisms in their language. You have to specify various 'policies' in your build script, if you want certain old crufty things to happen.