Réponse.

Les structures map et slice en Go ont des particularités importantes en matière de copie et de sémantique de travail avec la mémoire, qui entraînent souvent un comportement inattendu chez les développeurs inexpérimentés.

Historique de la question

Bien que Go soit considéré comme un langage rigoureux avec une typage statique et l'absence de pointeurs par défaut, map et slice ont un modèle interne spécial : les deux types sont des structures de référence. Cela impose des restrictions et crée de nombreux enjeux lors de la copie et du passage de ces objets.

Problème

La copie de map et slice ne conduit pas à une copie profonde du contenu, mais crée une nouvelle référence au même objet, ce qui entraîne des effets secondaires inattendus lors de la modification des données, d'un retour incorrect de valeurs depuis des fonctions et de modifications. De plus, le retour d'une map ou d'un slice comme résultat d'une fonction peut provoquer des allocations supplémentaires ou des fuites.

Solution

Lors de la copie d'un slice, le nouveau slice pointe vers la même zone de mémoire, s'il a été obtenu par slicing (b := a[:]). Pour une copie complète des éléments, il faut utiliser la fonction intégrée copy().
La copie d'une map crée une copie superficielle du pointeur. Pour un clone profond, il est nécessaire de parcourir le cycle et de copier chaque paire clé-valeur.
Le passage d'un slice ou d'une map dans une fonction se fait par valeur, mais c'est une structure décrivant les données qui est passée.

Exemple de copie correcte :

// Copie d'un slice
a := []int{1, 2, 3}
b := make([]int, len(a))
copy(b, a) // b est maintenant indépendant de a

// Copie d'une map
src := map[string]int{"x": 1}
dst := make(map[string]int)
for k, v := range src {
    dst[k] = v
}

Caractéristiques clés :

slice et map sont des types de référence, copiés par descripteur, et non par contenu
Pour un clone complet, il faut copier manuellement (ou via copy pour slice) toutes les données
Le passage à une fonction ou le retour depuis une fonction ne copie pas le contenu : les deux participants peuvent modifier les données communes

Questions pièges.

Que se passe-t-il si on assigne simplement une map/slice à une autre, puis qu'on modifie l'une d'elles ?

Les deux map et slice pointeront vers les mêmes données en mémoire : la modification affectera les deux objets.

Pourquoi dit-on souvent que retourner un slice ou une map depuis une fonction est "efficace en mémoire" ?

Parce qu'un clone du descripteur est retourné, et non de l'ensemble du contenu, les données dans le tas vivent tant qu'il y a des références sur elles.

Peut-on faire une "copie profonde" d'une map avec la fonction copy() ?

Non, copy() ne fonctionne qu'avec des slices et des tableaux, pour les maps, il faut toujours une boucle.

Erreurs communes et anti-patrons

Assigner une map ou un slice l'un à l'autre, espérant l'indépendance, et obtenir des effets secondaires inattendus
Laisser des références "pendantes" sur un slice, puis modifier la source, rompant les invariants
Utiliser la fonction copy() à d'autres fins, en l'appliquant à une map

Exemple de la vie réelle

Cas négatif

Un développeur copie un slice ou une map par assignation et modifie la copie pour se protéger contre les effets secondaires :

Avantages :

Économise du temps de codage
Moins de variables temporaires

Inconvénients :

Modifications inattendues dans d'autres parties du programme
Bugs difficiles à localiser à cause du partage "invisible"

Cas positif

Avant de modifier les données nécessaires, la fonction copy() est utilisée pour les slices et une boucle pour les maps :