Was sind Value Semantics in Swift und wie kann man unerwartete Datenänderungen bei der Übergabe von Strukturen und Sammlungen vermeiden? Wie unterscheidet sich Copy-on-Write vom klassischen Kopieren?

Antwort.

In Swift haben Werttypen (struct, enum, tuple) so genannte Value Semantics: Bei der Übergabe oder Zuweisung an eine Variabel wird der gesamte Inhalt kopiert – es wird eine unabhängige Instanz erstellt. Dies hilft, eine Reihe von Schwierigkeiten mit shared state zu vermeiden, die charakteristisch für Referenztypen (class) sind.

Zur Optimierung des Speicherverbrauchs verwenden Sammlungen (z. B. Array, Dictionary, Set) jedoch die Strategie Copy-on-Write: Das Kopieren erfolgt nur, wenn eine der Instanzen geändert wird.

Beispiel:

var a = [1, 2, 3]
var b = a
b.append(4)
print(a) // [1, 2, 3]
print(b) // [1, 2, 3, 4]

Hier wird das Array a nicht verändert – obwohl ursprünglich ein gemeinsamer Speicher vorhanden war, erstellt Swift bei der Änderung von b eine separate Kopie der Daten.

Es ist wichtig zu beachten: Wenn eine Struktur einen Referenztyp (z. B. eine Klasse) enthält, ist Value Semantics nur auf die Struktur selbst anwendbar, nicht auf die eingebetteten Referenzobjekte.

Fangfrage.

Wird der Inhalt des Arrays geändert, wenn wir es an eine Funktion übergeben und innerhalb dieser Funktion bearbeiten? Erklären Sie den Unterschied im Verhalten zwischen struct und class.

Antwort mit Beispiel:

func mutate(_ arr: inout [Int]) {
    arr.append(100)
}

var source = [1, 2]
mutate(&source)
print(source) // [1, 2, 100]

Wenn nicht über inout übergeben wird, erfolgt das Kopieren automatisch bei der ersten Änderung innerhalb der Funktion, und das ursprüngliche Array ändert sich nicht. Bei Klassen erfolgt jedoch kein Kopieren – das ursprüngliche Objekt wird immer verändert.

Beispiele für reale Fehler aufgrund mangelnden Wissens über die Feinheiten des Themas.

---

Geschichte

Entwickler legten Referenzobjekte in ein Array von Strukturen (struct), in der Erwartung, dass eine Änderung über eine Struktur andere Instanzen nicht betreffen würde. In Wirklichkeit änderten sich die Referenzobjekte an einem Ort unerwartet überall (shared state).

---

Geschichte

In einem Teamprojekt versuchte man, sich vor Race Conditions zu schützen, indem man Sammlungen bei jedem Zugriff kopierte. Dies führte zu unerwartetem Speicheraufwand und Leistungseinbußen beim Arbeiten mit großen Arrays.

---

Geschichte

Ein junger Entwickler versuchte, Änderungen im Array zu verfolgen, weshalb er es gleichzeitig in mehrere Handler-Funktionen über inout übergab. Die Reihenfolge der Modifikationen wurde unklar, was zu nicht threadsicheren Änderungen, Bugs und Synchronisationsfehlern führte.