I learned that we could get rid of the return as well to have the best practice :)

That's just another way of writing the same thing. It comes down to personal preference. Although, I would argue that since guard is specifically meant for returning early from a closure, which is what we're doing here, it makes more sense in this context than if.

Why would you use guard here? Can't we just write if (num < 3) { return 0 }?

Exactly what i was thinking. I first tried it like above, but it was throwing me an error. But i think mainly because i used "for i in 1..<num" and it was checking with 0.

I nested the whole thing in a "if num > 0 {...} else {return 0}" but mainly cause i'm not much familiar with guard. :D Thanks, gonna look into that again.

Hello Krazy! Thank you, the description is good now, so I hope it will be clearer for future warriors.

The description indicates that memory can be extended infinite in both directions. can you mark this as resolved?

And I just solved this kata in Java - found out that it doesn't support Java only when I tried to submit my solution. Well, I've learnt my lesson - always check supported languages before starting work on a kata.

You could remove areAllElementsZero and simply check if max==0, seen that max is being calculated anyways. If max is zero then all elements must be zero.

And yes, the boolean isMerge is unnecessary, a simple direct return would have been sufficient here. I just saw this after submitting the code... :-)

Just change the input and return types of your solution from long[] to int[] and it will work.