Slice vs Map: Understanding Parameter Reference Behavior

In Go, slices and maps both represent reference types. When modifying an element in either type, the change reflects in all slices/maps derived from them. This shared modification behavior results from the pointer-based implementation of maps, where modifications made through a pointer apply to the original map.

However, when adding new elements, slices and maps behave differently. In the provided code example, appending new elements to a map (editMap) results in those elements being accessible through the original map. However, appending to a slice (editSlice) has no effect on the original slice.

This discrepancy stems from the underlying implementation differences between slices and maps. Maps are implemented as pointers to hash map structures, while slices are lightweight structs that reference an array. When adding a new element to a map, the pointer remains constant, leading to the visibility of the new element in all derived maps.

Contrastingly, when appending to a slice, the slice header (describing the slice's length, capacity, and array pointer) must be modified. However, since Go passes variables by value, any changes made to the copy of the slice header (in the passed-in parameter) are not reflected in the original slice.

To achieve consistent behavior between slices and maps, one could implement slices as pointers, similar to maps. This would ensure that modifications made through pointers to slices also modify the original slice. However, this approach is uncommon in Go due to the lack of language support for passing and working with slice pointers. Instead, the convention of returning new slices after modification is widely adopted.