Introducción

En el artículo anterior vimos qué son las constantes en Go: valores fijos, evaluados en tiempo de compilación y con reglas propias, distintas a las de las variables.

Allí dejamos caer una idea importante, pero no la desarrollamos:

No todas las constantes en Go se comportan igual cuando entran en juego los tipos.

Ese comportamiento no es accidental. Forma parte del diseño del lenguaje y es una de las claves para entender por qué Go puede ser, al mismo tiempo, estricto y expresivo.

En este artículo vamos a dar el siguiente paso: entender qué significa que una constante sea tipada o no tipada, cuándo ocurre cada caso y cómo afecta esto al diseño del código.

| Siempre tienen un tipo concreto | El tipo puede decidirse mas tarde |

Esta última diferencia es especialmente importante y conviene detenerse a explicarla mejor.

El compilador asigna un tipo a las variables desde el mismo instante en el que se declaran. Sin embargo,·

Las variables tienen un tipo desde el moment

. En Go, no todas las constantes tienen un tipo asociado desde el momento en que se declaran. El lenguaje permite que ciertas constantes permanezcan “sin tipo” hasta que el contexto de uso exige uno concreto. Este comportamiento no es accidental: forma parte del diseño del lenguaje y permite escribir código más expresivo y flexible. Volveremos sobre esta idea en un artículo dedicado exclusivamente a las constantes tipadas.

El compilador pospone la elección del tipo concreto de la constante hasta que existe un contexto que lo exige, pero siempre durante la compilación, nunca en ejecución.

Introducción

En el artículo anterior vimos qué son las constantes en Go y cómo representan valores fijos evaluados en tiempo de compilación.

También dejamos caer una idea importante: no todas las constantes tienen un tipo asociado desde el principio. Ese comportamiento es intencionado y forma parte del diseño del lenguaje.

En este artículo vamos a dar el siguiente paso: entender qué son las constantes tipadas, cuándo aparecen, cómo se comportan y por qué Go permite que una constante tenga o no tenga tipo según el contexto.

Este es un punto clave para comprender el sistema de tipos de Go sin confusiones. Constantes sin tipo: el punto de partida

Cuando escribes una constante como esta:

const x = 10

x no tiene todavía un tipo concreto. Es simplemente el valor literal 10, disponible para ser usado en distintos contextos.

Esto permite algo muy potente:

const x = 10

var a int = x var b int64 = x var c float64 = x

El mismo valor puede adaptarse a distintos tipos sin conversiones explícitas, siempre que el valor sea representable.

Este comportamiento solo existe para constantes. Las variables no funcionan así. Cuándo una constante pasa a estar tipada

Una constante se convierte en constante tipada cuando su tipo queda fijado explícitamente o implícitamente.

Hay dos formas principales de que esto ocurra.

1. Tipado explícito

Puedes indicar el tipo de una constante directamente:

const x int = 10

A partir de ese momento:

x sí tiene tipo

Ese tipo no puede cambiar

El valor deja de ser “flexible”

Ejemplo:

const x int = 10

var a int = x // correcto var b int64 = x // ERROR

El compilador ya no puede adaptar el valor a otro tipo porque el tipo quedó fijado en la declaración. 2. Tipado por contexto

Una constante también puede quedar tipada cuando se usa en un contexto que exige un tipo concreto.

Ejemplo:

const x = 10

var a int = x

Aquí ocurre algo importante:

x era una constante sin tipo

al asignarla a a, el compilador la interpreta como un int en ese contexto

x sigue siendo sin tipo en general, pero se usa como int aquí

Esto es sutil, pero fundamental. Constantes tipadas vs no tipadas

La diferencia no está en el valor, sino en la flexibilidad del tipo. Constante sin tipo

No tiene tipo fijo

Se adapta al contexto

Permite reutilización sin conversiones

Existe solo en compilación

Constante tipada

Tiene un tipo concreto

No se adapta

Se comporta como un valor de ese tipo

Tiene reglas más estrictas

Ejemplo comparativo:

const a = 10 const b int = 10

var x int64 = a // correcto var y int64 = b // ERROR

Por qué Go permite constantes sin tipo

Este diseño no es accidental. Permite:

Expresar valores universales (0, 1, -1, π)

Evitar conversiones innecesarias

Escribir código más limpio y legible

Mantener seguridad en compilación

Las constantes sin tipo no rompen el sistema de tipos; lo refuerzan, porque el compilador controla en todo momento si el valor es representable o no.

Ejemplo:

const big = 1e100

var x int64 = big // ERROR: overflow

El compilador detecta el problema antes de ejecutar nada. Cuándo conviene usar constantes tipadas

Aunque las constantes sin tipo son muy flexibles, hay situaciones donde tipar explícitamente una constante mejora el diseño:

APIs públicas

Valores con semántica fuerte

Constantes que representan unidades, tamaños o límites

Código que actúa como documentación

Ejemplos:

const MaxRetries int = 5 const TimeoutSeconds int64 = 30

Aquí el tipo comunica intención, no solo almacenamiento. Constantes, tipos y diseño del código

Un patrón común en Go es:

usar constantes sin tipo para valores genéricos

usar constantes tipadas cuando el tipo forma parte del significado

Esto da lugar a código que es:

más expresivo

más seguro

más fácil de mantener

No es una decisión técnica obligatoria, sino una herramienta de diseño. Resumen mental

Las constantes pueden ser tipadas o no tipadas

Las constantes sin tipo se adaptan al contexto

El tipo puede fijarse explícitamente o por uso

Una constante tipada pierde flexibilidad

El compilador garantiza siempre seguridad en compilación

Conclusión

Las constantes tipadas y no tipadas son una de las piezas más elegantes del sistema de tipos de Go.

Lejos de ser una rareza, este comportamiento permite combinar:

flexibilidad

seguridad

claridad semántica

Entender esta diferencia es clave para escribir Go idiomático y para comprender por qué el lenguaje puede ser tan estricto y tan cómodo al mismo tiempo.

En el siguiente artículo entraremos en un caso muy especial donde todo esto cobra aún más sentido: iota y la construcción de enumeraciones en Go.

Ahí es donde muchas piezas terminan de encajar.