A few of the built-in functions are very special, in that they can evaluate to constant expressions. len and cap are two such functions.

But they aren’t always evaluated to constant expressions, sometimes they’re more normal-ish runtime functions.

Length and capacity

…

The expression len(s) is constant if s is a string constant. The expressions len(s) and cap(s) are constants if the type of s is an array or pointer to an array and the expression s does not contain channel receives or (non-constant) function calls; in this case s is not evaluated. Otherwise, invocations of len and cap are not constant and s is evaluated.

const (
	c1 = imag(2i)                    // imag(2i) = 2.0 is a constant
	c2 = len([10]float64{2})         // [10]float64{2} contains no function calls
	c3 = len([10]float64{c1})        // [10]float64{c1} contains no function calls
	c4 = len([10]float64{imag(2i)})  // imag(2i) is a constant and no function call is issued
	c5 = len([10]float64{imag(z)})   // invalid: imag(z) is a (non-constant) function call
)
var z complex128

The example provided in the spec demonstrates a few examples of constant len() expressions by assigning the results to constants. But the fact that len() and cap() may resolve to constants has much more broad application.

First, it can be a simple compiler optimization to use constant expressions, rather than variable expressions, where possible. Take for example, something as simple as:

fmt.Println(len(x))

If the compiler is able to, according to the rules above, it will evaluate len(x) as a constant, and thus save the effort of calculating it every time the program runs this line of code. For something simple like a print statement, such an optimization is pretty accademic. But in some cases, such an optimization can be significant. And every little optimization adds up.

Quotes from The Go Programming Language Specification Language version go1.23 (June 13, 2024)