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

[Mickeon]

I find that pass is a acceptable compromise to a theoretical end keyword. It's optional, it doesn't do anything, and it can denote the end of a code block just fine depending on your style. Some of my older code has it for this purpose for clarity, as well. I thought I was the only one.

We could handle pass a bit more specially to make it intended for this purpose, too. You'd be hard-pressed to find more than one pass in one block, so... hmm...

I feel like a better look for code indentation would go a long mile to address the confusion, at least when reading code.

[cyb3rkun]

I agree that pass can be used for this purpose.

but I think using something like end would add more clarity, and would be more consistent.

I don't really like using pass so I prefer return where I can.
but it's not always possible

[kitbdev]

This cannot really be used for formatting / auto indentation since this is optional. If there are too few or too many end keywords, then you can't know for sure what block each one is meant to be for, which means it still needs the existing indentation anyway.
One of the cases where auto indentation is the most useful is when copying code from elsewhere that has messed up indentation, but if they don't use end keywords or you don't, then you can't use auto indentation and you still have to fix it manually.
The only way to make it reliable is to make it not optional, which of course can't really be done.

Also if your goal with this is just to make pressing enter after a block use the correct indentation, then this makes it even worse. You will have to add the end keywords yourself at the end of each block when writing it and they will all force you to remove extra indentation to put them where you want every time, since they haven't been added yet. They also can't be automatically added or moved since they are optional.

[cyb3rkun]

yeah, although I could easily define code snippets to add them automatically in most cases I can see that would be inconvenient for the vast majority of users..

thanks for hearing me out though.