Aliasing con append en Go: probar tanto la ruta de capacidad sobrante como la de reasignación

Qué es

El artículo de Go sobre slices explica que un slice es una vista sobre un array subyacente y que volver a hacer slice no copia ese array. Un append puede reutilizar la capacidad disponible o asignar almacenamiento nuevo. Por tanto, dos llamadas de aspecto similar pueden mostrar un comportamiento de aliasing distinto según la capacidad del slice de entrada. Go slices: usage and internals

Por qué importa

Un agente puede añadir una prueba usando un slice corto recién asignado y concluir que un helper preserva su entrada. Quien llama en producción puede proporcionar una vista con capacidad sobrante. Especificar si el helper toma prestado almacenamiento mutable o debe devolver datos independientes, y luego probar ese contrato deliberadamente.

Cómo aplicarlo

• Dibujar el array subyacente y el inicio, la longitud y la capacidad de cada slice. Identificar qué valores existentes podrían sobrescribirse si un append reutiliza el almacenamiento.
• Indicar en la documentación del helper su contrato de propiedad. Si el resultado debe ser independiente, copiar los datos relevantes a un almacenamiento con propiedad separada, en lugar de confiar en que un append termine reasignando.
• Proponer dos fixtures con los mismos valores de entrada visibles: uno con capacidad sobrante y otro que requiera crecimiento. Conservar un slice observador separado para detectar mutaciones no intencionadas.
• Incluir tanto la actualización ordinaria de un elemento como el comportamiento de append. Restringir solo la capacidad de append no hace independientes a los elementos ya compartidos.
• Para un resultado pequeño retenido a partir de una entrada grande, considerar el tiempo de vida del array subyacente. Revisar si una copia explícita expresa el límite de retención pretendido.

Trampas

No inferir una política estable de crecimiento de asignación a partir de una única observación en tiempo de ejecución. Copiar también tiene un coste, así que elegirlo porque la propiedad lo exige, no como una prescripción de rendimiento universal. La compartición concurrente añade cuestiones de sincronización que son independientes de este diagnóstico de aliasing. Los fixtures propuestos muestran qué verificar; aquí no se afirma ningún benchmark de asignación ni ahorro de memoria medido.