Adding an End keyword at the end of a function/loop/if.

[cyb3rkun]

Describe the project you are working on

In this case this doesn't really matter as it's not a feature that would be tied to a specific project.

it's more just syntactic sugar that would make auto indentation easier (especially for external editors like vsCode, Neovim etc.)

first suggested here

and like I mention in that discussion I don't think that it should be enforced but an optional keyword for those who want better auto indentation and who just like having that type of syntax.

while at the same time those who don't want to use it would have no need to do so and should still be able to write gdscript the way they've always been.

Describe the problem or limitation you are having in your project

without an end keyword or some type of symbol denoting the end of a function, if/ loop or any other kind of block it makes auto indentation very difficult to do.

it's not a big issue but I'm very used to languages like c where that's never an issue and an editor can very easily auto indent code because the start and end of any block is clearly denoted with brackets.

I'm a neovim user and when I press enter at the end of a function then I have to first erase the tabs at the beginning of a line since it would continue at the previous indentation level.

so for instance if I had the following:

func foo():
      if this:
            dosomething()
      else:
            dosomethingelse() |< # imagine cursor here at end of line

and I then press enter:

func foo():
      if this:
            dosomething()
      else:
            dosomethingelse() 
            |< #  cursor now here

when in actuallity I intended for it to be at the first level of indentation to start writing another function.

this becomes a very tedious thing to deal with and while one could use and
at the end of a function/if, it's not really intended for that purpose and their indentation level won't match the function definition's indentation level:

func foo():
      if this:
            dosomething()
            pass
      else:
            dosomethingelse() 
            return
      pass
|< #  cursor now here after entering

Describe the feature / enhancement and how it helps to overcome the problem or limitation

simply add an optional end keyword to denote the end of a block:

func foo():
      if foo:
            print("this is foo!")
      else
            print("where is foo?")
      end
end

and since the end would literally be syntactic sugar with no real meaning you could even do this:

func foo():
      if foo:
            print("this is foo!")
      end
      else
            print("where is foo?")
      end
end

and it would be the exact same thing. (although I probably wouldn't use it like that.)

and like I said I don't think this should be an enforced syntax, just like using pass is mostly optional (unless you have empty functions?)

some people might use this as they prefer that type of syntax, others might use it for better auto indentation.

and others might decide not to use it at all.
it should be up to them.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I have no Idea how writing a scripting language works so unfortunately I can't provide any psuedo code for it's implementation.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Definitely not.
I don't believe one can make changes to gdscript inside of gdscript.

Is there a reason why this should be core and not an add-on in the asset library?

because it would add a core feature to the gdscript syntax. it can't be implemented as an addon. (at least not to my knowledge)

[Calinou]

Supporting two different syntaxes in GDScript would make the implementation and tooling a lot more complex, so I don't think it's a good idea.

With 2025 hindsight, it's clear that braces/keywords are better suited for refactoring and tooling compared to an indentation-based syntax. However, I don't think we can make such a major change to GDScript (even in 5.0) now that it's an established language with a lot of third-party tools supporting it.

[cyb3rkun]

I understand and that's why I'm suggesting that the end keyword's use should NOT be enforced.
that would make it backwards compatible with scripts that people have already written.
while allowing a syntax that makes refactoring much easier.

it would be an optional keyword, thus it shouldn't cause any conflicts or issues with the way gdscript used to work before it's added.

other than it being a visual que and allowing for clear end of code blocks it would functionally do nothing, and therefore gdscript as a whole wouldn't really change at all.

I don't understand what you mean by supporting two syntaxes.

If you mean that the end keyword would make it so that gdscript would no longer be an indentation based language. that's not what I'm suggesting.

the linter? i think wouldn't have to change at all.
the end keyword would simply be a new token, but one that does nothing, and is ignored by the linter/compiler/interpreter?.

as such gdscript would still require proper indentation, just like it always have, but since there would be a clear indication of the end of code blocks, editors that use smart indentation could still do that part properly.

and treesitter textobjects would work much better and consistently since they could then make use of that to select blocks of code.

[Zireael07]

@Calinou Interesting finding: https://koka-lang.github.io/koka/doc/book.html#sec-layout automatically adds braces where indented