If you only want the "guard" in editor and not in your release, you can use the Assert keyword.. Otherwise, the pattern xyz shared is very common.

I'm not familiar with Swift at all. Just looked up how guard operates there. It's just if not with some additional syntactic sugar. Completely redundant imho.

    xyz Now now, let's not be too dismissive of "syntactic sugar". All control-flow statements are just "goto" with extra sugar. :-)

        I've fond memories of it with QuickBASIC back from the 90's. But I understand why it was hated by many.

          A lot of things could be called redundant but make code more readable, safer and show intent.

          Haystack Now now, let's not be too dismissive of "syntactic sugar". All control-flow statements are just "goto" with extra sugar. :-)

          Sure if you want to play reductio ad absurdum. But let's be pragmatic here. I'd like to hear actual benefits of guard over if not. It doesn't make code any simpler or more readable. It just introduces an extra keyword to do the same thing the if does.

          So to answer the initial question directly - the GDScript equivalent is if not.

              xyz So to answer the initial question directly - the GDScript equivalent is if not.

              Perhaps, but I really like @award's idea of making use of assert instead. I'm inclined to say it's potentially better than any of the alternatives, swift's guard included...

                  xyz Ok, a less silly reply:

                  Like you, I don't see the point of 'guard', but I'm not a Swift coder, and I've learned to reserve judgement on different programming language features until I've coded a mile in that language. Most of my work has been in C++, but I've had to use a lot of other languages over the years. When I first learn another language, I see it from a "C++" viewpoint, and tend to implement everything in a C++-ish way, and so don't see the value of language features not in C++. But after really using the language for a while, I often see that features I initially dismissed do have real value.

                    So I read up some more about it. Looks like the main benefit of Swift's guard over regular if is that its else block must exit the enclosing scope via continue, return, break or throw. It's a "safer" version of early exit because compiler forces you to code in one of the exit statements and can check at compile time if you did so. I guess the intent behind it was to eliminate certain types of runtime errors.

                    Again, the equivalent is if not but you don't get the compiler to check for you whether you're exiting the scope or not.

                    Megalomaniak Perhaps, but I really like @award's idea of making use of assert instead. I'm inclined to say it's potentially better than any of the alternatives, swift's guard included...

                    assert() has the limitation that it's only effective in a Debug build. In a Release build, it's ignored. Does that also apply to guard?

                    Here's a way to misuse assert:
                    assert(button.pressed.connect(_on_button_pressed) == OK)
                    In a Release build, that statement would not be executed, so the signal would not be connected.
                    Instead, you could do this:

                    var err: Error = button.pressed.connect(_on_button_pressed)
assert(err == OK)

                      @Megalomaniak @DaveTheCoder
                      assert in not really in the same category. Its fail will always throw a runtime exception. guard on the other hand is just a regular if with some special compile-time requirements. At least that's my understanding of things from reading about it for 5 minutes 🙂 Though, I'd like a Swift coder to confirm this is indeed so.

                      13 days later

                      A tad late, but I wanted to thank everyone for their input! Highly appreciated! 🙂

                      It may be something more specific in Swift, but the "Guard clause" concept is a clean code practice that can be used in all languages, as a way to help improve readability by keeping the code shallow. For example, instead of doing:

                      if a:
    if b:
        if c:
            do_stuff()

                      or having a long line with several conditions:

                      if a and b and c:
   do_stuff()

                      You return early:

                      if not a:
   return

if not b:
   return

if c:
    do_stuff()

                      I always try to keep my functions below 2 levels of depth and it helps A LOT when I have to read through them hunting bugs. So, even if Godot doesn't implement Swift's guard, you will still benefit a lot from using the "regular" guard clause in GdScript (or in any language, really).