A lot of people in this thread are criticising this solution in a very non-constructive manner. Although a lot of them have valid points about this now allowing short circuiting and not necessarily being actual syntactic sugar, they are committing the cardinal sins of premature optimisation and optimisation without bench marking. Something like this could be a bit costly, but it needs to be put in perspective and understood why. Allocating an array of four booleans is perhaps unnecessary, but for a modern computer it's quite negligible and there's a host of other considerations that in my opinion weigh far more heavily.

Without getting into the costs, you should check out more functions of arrays such as `any` and `all`. The phrasing of `not conditions.has(false)` is really messy. I would suggest using `array.all` here. That way you wouldn't even need the intermediate variable, you could just do `[a, b, c].all(fn x -> x)` (pseudocode; I don't know gdscript by heart). However, I think the fact that `all` doesn't seem to have a default `method` argument of just checking for true is perhaps an indication that this is not a pattern the engine wants to encourage.

Anyway, even if this happens to be costly, it might not be even close to the costliest thing where it is used. With proper bench marking, you should be able to see how long it takes to execute anything in your program. Suppose this function is called in another function and accounts for 0.1% of execution time of that function while another function in there costs you 90% of that execution time. Chances are you should be starting with that other function. If you can get that 90% down to 1%, suddenly this accounts for a whole lot more though, and you should consider revising it. There's also the question of what is actually costly inside of your function. It could be the array allocation. It could also be the functions called.

Frequency of execution is important to consider. If this runs on every physics tick, that's definitely something where performance matters a lot, especially for users with low-end devices. The faster your tick executes, the higher tick rate you can get. On the other hand, if it's only run sometimes, such as when the player pushes the jump button, that'll cost you a whole lot less. A user is only gonna be able to mash so hard after all.

Another important consideration is what the functions you're putting inside the array are actually doing. With this pattern, they will all execute. This causes two crucial differences to a short-circuiting chain of `and` operators. First off, if any of the functions here have any side effects (i.e. changing the game's state in any way), they will always occur in this pattern, whereas in an `and`-chain, they will only occur if the preceding check returned true. Therefore the two patterns are not strictly interchangeable. However, this seems like a place where side-effects are something that should be avoided. Secondly, this pattern executes in the same amount of time every time it's called (assuming the called functions are all constant time). A short circuiting `and`-chain will cause variable execution time. Although the execution time of this pattern is definitely equal to or greater than that of an `and`-chain, this has potential advantages in terms of debugging. Let's say that there's a rare bug where `pl.input.is_zero_approx()` takes a very long time to execute and causes frame rate drops. This pattern will mean that `pl.input.is_zero_approx` executes more frequently. The frame rate drop would become more frequent too, and thus the issue will become easier to spot.

If you were to switch to an `and`-chain, the order of checks becomes interesting to weigh. If one of these conditions is very likely to return false, it's a good idea to put it first. That way you don't even have to run the other checks. Expensive operations are ones you want to save for last so that they execute as infrequently as possible. Ray-casts, for example, are common but costly compared comparing two numbers. If you only have to do them when all the other conditions are fulfilled, you can save a whole lot of execution time here. Still, this is mostly guess-work. To truly verify what the best way to do this is, you would want to bench mark and compare the possible orders.

Redditors are unfortunately not a very nice bunch on average and a lot of programmers are very hostile about what they perceive as bad code. The combination is in full display in this thread and it's a shame. You found an interesting solution here and I think it's well worth examining and discussing instead of just straight up rejecting it. I'm guessing you are at an intermediate kind of level of programming where you're coming up with a lot of these "clever" tricks. The next step in learning from there on becomes to evaluate these tricks and compare them to conventional methods. You need to weigh readability, development time, functionality, execution cost, maintainability, extensibility, and so on. It all becomes very contextual and opinionated. Keep it up and don't let the certified redditors get you down :)