Hello Godots!

I've just taken the big step and moved from Unity to Godot and I love it so far. Before Unity, I used to work in Swift. I should probably mention that I'm a hobby-programmer so I'm still - and might forever be in the learning stadium. 😃

Back in the "Swift" days I was fairly happy with the "guard" statemention which basically worked - as it implies - as a guard. Ex.: "if this condition is not met, do no read any of the code below".

I've been snooping around for a Godot equivalent the last few hours without luck, so I thought I'd give it a quick try here.

Might any of you know of such a thing? 🙂

If I managed to totally overlook the obvious, I'm sorry for wasting time and forum-space! 🙂

Kind regards,
Theloneswiftman

  • Toxe replied to this.

    What would be the difference to a plain old if statement in the context of GDScript. I don't see any.

      Zini Thanks for the quick reply!

      Pardon me, if I'm mistaken - but in the "if statement" I have to put everything inside that statement. In the "guard statement" it simple just skips the code below if the condition is not met.

      There are probably not any noteworthy advantage with the "guard statement" it's just a style of programming which I happen to dig, hence my search for an equivalent in GDScript. 🙂

        Zini Suspected that, but as I mentioned in the post, it was a longshot 😀 Anyway, thanks for the quick replies! 🙂

        • xyz replied to this.

            theloneswiftman Use a function with if at the beginning.

            func guarded():
	if not condition:
		return
	# do stuffs

              theloneswiftman Ah, Swift. I never really used it much sadly but I had a really good time when I learned it 10'ish (?) years ago.

              But no, no such thing in GDScript. And you'll learn that GDScript is a fairly simple language in general. Although this isn't necessarily a bad thing considering that Godot is an engine that is a pretty good choice for beginners.

                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! 🙂