Arrays constantes en Go: cómo declararlos y no volverse loco

Introducción: la pregunta eterna de Stack Overflow

Si alguna vez has buscado en Google "Declare a constant array in Go", seguramente has visto ese mismo hilo en Stack Overflow con miles de visitas. Y sí, no estás solo en tu confusión. En Go realmente no se puede simplemente escribir const arr = [...]int{1, 2, 3} — el compilador te dirá un cortés "no".

¿Por qué es así? ¿Y qué hacer entonces si necesitamos una lista de datos inmutable? En este artículo analizaremos la naturaleza de las constantes en Go, descubriremos por qué los arrays no pueden ser constantes y encontraremos las mejores soluciones alternativas. Spoiler: la solución existe, y es incluso más elegante de lo que piensas.

¿Por qué Go no permite declarar un array constante?

Para entenderlo, hay que mirar bajo el capó del lenguaje. En Go, las constantes son valores inmutables calculados en tiempo de compilación. Deben estar estrictamente tipificadas y ser conocidas antes de ejecutar el programa. Los arrays, en cambio, son tipos de datos compuestos que ocupan memoria y pueden modificarse.

Aquí hay un ejemplo simple que NO se compilará:

package main\n\nconst arr = [3]int{1, 2, 3} // Error: const initializer [3]int{1, 2, 3} is not a constant\n\nfunc main() {\n    fmt.Println(arr)\n}

El compilador dice: "¡Oye, esto no es una constante!". Y tiene razón. Incluso si el array se declara como const, Go no garantiza que su contenido no cambiará a través de punteros o slices. Por eso, los desarrolladores del lenguaje decidieron: nada de arrays constantes.

Pero no te apresures a frustrarte. Hay al menos tres formas de sortear esta limitación, y cada una tiene sus ventajas.

Forma 1: Usar una variable con un comentario "no tocar"

La forma más simple e ingenua es simplemente declarar una variable y esperar que nadie la modifique. Pero somos desarrolladores serios, ¿verdad?

package main\n\nimport "fmt"\n\n// arr - array constante. Por favor, no lo modifiques.\nvar arr = [3]int{1, 2, 3}\n\nfunc main() {\n    fmt.Println(arr)\n    // arr[0] = 100 // Descomenta esto y todo se romperá\n}

Las desventajas son obvias: no es una constante real. Cualquiera puede modificar el array mediante asignación. Pero para prototipos rápidos o proyectos pequeños, sirve.

Forma 2: Función getter (el camino correcto)

Este enfoque se usa en código de producción. Ocultamos el array dentro de una función y devolvemos una copia del mismo. Así, nadie podrá modificar el original.

package main\n\nimport "fmt"\n\n// getColors devuelve una copia del array de colores.\n// El array está protegido contra modificaciones externas.\nfunc getColors() [3]string {\n    return [3]string{"Rojo", "Verde", "Azul"}\n}\n\nfunc main() {\n    colors := getColors()\n    fmt.Println(colors)\n    // colors[0] = "Amarillo" // Esto modifica la copia, no el original\n}

¿Por qué esto es bueno? Porque:

\n
• El array no puede modificarse desde fuera: la función devuelve una copia.
\n
• El código es legible y comprensible.
\n
• Es fácil de probar y mantener.
\n

Pero hay un detalle: cada llamada a la función crea una nueva copia del array. Si el array es grande (por ejemplo, 1000 elementos), esto puede ser costoso. En ese caso, usa la siguiente forma.

Forma 3: Variable de paquete con acceso privado

Si estás escribiendo un paquete y quieres proteger el array de modificaciones, hazlo no exportable (con minúscula) y proporciona acceso a través de una función.

package constants\n\n// El array solo es accesible dentro del paquete\nvar defaultPorts = [5]int{80, 443, 8080, 3000, 5000}\n\n// GetDefaultPorts devuelve una copia del array de puertos.\nfunc GetDefaultPorts() [5]int {\n    return defaultPorts\n}

Ahora los usuarios de tu paquete solo pueden leer los datos, pero no modificarlos. Ideal para bibliotecas.

Forma 4: Uso de iota para conjuntos constantes

¿Y si lo que necesitas no son los valores en sí, sino sus índices? Por ejem