Use spoiler flag next time please.

How can this be voted best practices? It is very slow and only work with ascii strings 🤔

What is the best practice for Unicode strings then?

now I learned that in golang you have runes not characters.
why not :)
at least not hieroglyphs

Suprised so many have upvoted this. Concatination is slow and it does not work for non ASCII strings.

Concatination via + is slow.

So long as everything in the string can be contained in a single byte, this solution is fine. I'm trying to get into the habit of not assuming single bytes unless explicitly stated, though, so prefer the rune solution.

Case sq = 1, this solution is bad. The next perfect square by 1 is 2 not 4.

Wow. By far the most understandable, intuitive and obvious solution so far. +1 for Best Practices

There are rounding problems with your test cases.

The first multiplication on the second line is the inverse of the function call on the first, the compiler shouldn't expect that, and the whole point of the multiplication is that it's not an inverse of the square root.

Caching repeated expressions is something every compiler is expected to know how to do, along with commuting additions and multiplications and inlining of small functions. Sometimes they'll even convert a cached value into a repeated expression, if they decide that register allocation is worth the extra CPU cycle. And modern CPUs won't even need that extra cycle.

By extra work, do you mean the ternary? I think it's better than spending five lines on the same.

You should assume that the compiler will execute your commands as you give them. Even if you wanted the compiler to handle that, it has no way to recognise that the first multiplication on the second line is the inverse of the function call on the first, especially when you've got a cast in between the two statements.

The extra work done on the second line also makes it hard to read.