Die Programmiersprache Rust

von Steve Klabnik und Carol Nichols, unter Mitarbeit der Rust-Gemeinschaft; übersetzt ins Deutsche durch die Rust-Gemeinschaft

Diese Version des Textes geht davon aus, dass du Rust 1.76.0 (veröffentlicht am 2024-02-08) oder später verwendest. Siehe Abschnitt „Installation“ in Kapitel 1 zum Installieren und Aktualisieren von Rust.

Die HTML-Version ist online verfügbar unter https://doc.rust-lang.org/stable/book/ (englisches Original) und unter https://rust-lang-de.github.io/rustbook-de/ (deutsche Übersetzung) sowie offline in Rust-Installationen, die mit rustup erfolgt sind; führe rustup docs --book aus um es zu öffnen.

Es sind weitere Gemeinschaftsübersetzungen verfügbar.

Der englische Text ist als Taschenbuch und E-Book bei No Starch Press erhältlich, den deutschen Text gibt es ebenfalls als Taschenbuch und E-Book.

Vorwort

Es war nicht immer so klar, aber bei der Programmiersprache Rust geht es im Grunde um Befähigung: Egal, welche Art von Code du jetzt schreibst, Rust befähigt dich dazu, weiter zu gehen, mit Vertrauen in einer größeren Vielfalt von Bereichen zu programmieren, als du es zuvor getan hast.

Denken wir zum Beispiel an systemnahe Arbeiten, bei denen Details wie Speicherverwaltung, Datenrepräsentation und Nebenläufigkeit wichtig sind. Traditionellerweise gilt dieser Bereich der Programmierung als geheimnisvoll und nur wenigen Auserwählten zugänglich, die die erforderliche Erfahrung gesammelt haben, um berüchtigte Fallstricke vermeiden zu können. Und selbst diejenigen, die damit arbeiten, tun dies mit Sorgfalt, damit ihr Code nicht angreifbar ist, abstürzt oder fehlerhaft ist.

Rust baut diese Barrieren ab, indem es die alten Fallstricke beseitigt und ein freundliches, ausgefeiltes Instrumentarium zur Verfügung stellt, das dich auf deinem Weg unterstützt. Programmierer, die in die systemnahen Kontrollebenen „eintauchen“ müssen, können dies mit Rust tun, ohne das übliche Risiko von Abstürzen oder Sicherheitslücken einzugehen und ohne die Finessen einer wankelmütigen Werkzeugkette erlernen zu müssen. Besser noch, die Sprache ist so konzipiert, dass sie dich auf natürliche Weise zu zuverlässigem Code führt, der effizient in Bezug auf Geschwindigkeit und Speichernutzung ist.

Programmierer, die bereits mit systemnahem Code arbeiten, können Rust nutzen, um ihre Ambitionen zu steigern. Beispielsweise ist die Einführung von Parallelität in Rust ein relativ risikoarmes Unterfangen: Der Compiler fängt die klassischen Fehler für dich ab. Und du kannst aggressivere Optimierungen in deinem Code wagen mit der Gewissheit, keine versehentlichen Abstürze oder Verwundbarkeiten einzuführen.

Aber Rust ist nicht auf systemnahe Programmierung beschränkt. Es ist ausdrucksstark und ergonomisch genug, um das Schreiben von Kommandozeilen-Anwendungen, Webservern und vielen anderen Arten an Code recht angenehm zu machen – du wirst später in diesem Buch einfache Beispiele dazu finden. Die Arbeit mit Rust ermöglicht es dir, Fähigkeiten zu entwickeln, die von einer Domäne auf eine andere übertragen werden können; du kannst Rust durch Schreiben einer Webanwendung erlernen und dann diese Fähigkeiten auf deinem Raspberry Pi anwenden.

In diesem Buch wird das Potenzial von Rust zur Befähigung seiner Nutzer voll ausgeschöpft. Es ist ein freundlicher und zugänglicher Text, der dir helfen soll, nicht nur dein Wissen über Rust zu erweitern, sondern auch deine Reichweite und dein Selbstvertrauen als Programmierer im Allgemeinen. Also tauche ein, mach dich bereit zum Lernen – und willkommen in der Rust-Gemeinschaft!

– Nicholas Matsakis und Aaron Turon

Einführung

Willkommen bei Die Programmiersprache Rust, einem einführenden Buch über Rust. Die Programmiersprache Rust hilft dir, schnellere und zuverlässigere Software zu schreiben. Ergonomie und systemnahe Kontrolle stehen beim Entwurf von Programmiersprachen oft im Widerspruch – Rust stellt sich diesem Konflikt. Durch den Ausgleich zwischen leistungsstarken, technischen Möglichkeiten und einer großartigen Entwicklererfahrung bietet dir Rust die Möglichkeit, Details systemnah (z.B. Speichernutzung) zu kontrollieren, ohne den ganzen Ärger, der damit typischerweise einhergeht.

Für wen Rust ist

Rust ist für viele Menschen aus einer Vielzahl von Gründen ideal. Schauen wir uns einige der wichtigsten Nutzergruppen an.

Entwicklerteams

Rust erweist sich als produktives Werkzeug in der Zusammenarbeit großer Entwicklerteams mit unterschiedlichem Kenntnisstand in der Systemprogrammierung. Systemnaher Code ist anfällig für eine Vielzahl subtiler Fehler, die in den meisten anderen Sprachen nur durch ausgiebige Tests und sorgfältige Überprüfung des Codes durch erfahrene Entwickler erkannt werden können. In Rust spielt der Compiler eine Art Pförtnerrolle, indem er Code mit diesen schwer fassbaren Fehlern verweigert zu kompilieren, darunter auch Nebenläufigkeitsfehler. Mit der Arbeit an der Seite des Compilers kann sich das Team auf die Programmlogik konzentrieren, anstatt Fehler zu suchen.

Rust bringt auch zeitgemäße Entwicklerwerkzeuge in die Welt der Systemprogrammierung:

• Cargo, das mitgelieferte Abhängigkeitsmanagement- und Bau-Werkzeug, macht das Hinzufügen, Kompilieren und Verwalten von Abhängigkeiten im gesamten Rust-Ökosystem schmerzlos und konsistent.
• Das Formatierungstool Rustfmt sorgt für einen einheitlichen Codierstil bei den Entwicklern.
• Der Rust Sprachdienst (Language Server) ermöglicht Codevervollständigung und im Code angezeigte Fehlermeldungen innerhalb der Entwicklungsumgebung (IDE).

Durch den Einsatz dieser und anderer Werkzeuge des Rust-Ökosystems können Entwickler produktiv arbeiten, während sie Code auf Systemebene schreiben.

Studenten

Rust ist für Studenten und alle, die sich für Systemkonzepte interessieren. Mit Rust haben viele Menschen etwas über Themen wie die Entwicklung von Betriebssystemen gelernt. Die Gemeinschaft ist sehr einladend und beantwortet gerne Fragen der Studenten. Durch Bemühungen wie dieses Buch will das Rust-Team Systemkonzepte mehr Menschen zugänglich machen, insbesondere denen, die neu in der Programmierung sind.

Unternehmen

Hunderte von Unternehmen, große und kleine, setzen Rust für eine Vielzahl von Aufgaben in der Produktion ein, dazu gehören Kommandozeilenwerkzeuge, Webdienste, DevOps-Werkzeuge, eingebettete Geräte, Audio- und Videoanalyse und -transkodierung, Kryptowährungen, Bioinformatik, Suchmaschinen, Anwendungen für das Internet der Dinge, maschinelles Lernen und sogar wesentliche Teile des Webbrowsers Firefox.

Open-Source-Entwickler

Rust ist für Menschen, die die Programmiersprache Rust, die Gemeinschaft, Entwickler-Werkzeuge und Bibliotheken aufbauen möchten. Wir würden uns freuen, wenn du zur Programmiersprache Rust beiträgst.

Menschen, die Geschwindigkeit und Stabilität schätzen

Rust ist für Menschen, die sich nach Geschwindigkeit und Stabilität einer Sprache sehnen. Mit Geschwindigkeit meinen wir sowohl die Geschwindigkeit, mit der Rust-Code ausgeführt werden kann, als auch die Geschwindigkeit, mit der du mit Rust Programme schreiben kannst. Die Prüfungen des Rust-Compilers gewährleisten Stabilität während du neue Funktionen hinzufügst und deinen Code änderst. Dies steht im Gegensatz zu brüchigen Code-Altlasten in Sprachen ohne diese Prüfungen, die Entwickler sich oft scheuen zu verändern. Durch das Streben nach kostenneutralen Abstraktionen, also Funktionalität auf höherer Ebene, die zu genauso schnellem Code wie manuell geschriebener Code auf niedrigerer Ebene kompiliert, bemüht sich Rust, sicheren Code auch zu schnellem Code zu machen.

Die Sprache Rust hofft, auch viele andere Nutzer zu unterstützen; die hier genannten sind nur einige der größten Interessensgruppen. Insgesamt ist es Rusts größtes Bestreben, den Zielkonflikt zu beseitigen, den Programmierer jahrzehntelang hingenommen haben, wenn sie Sicherheit und Produktivität bzw. Geschwindigkeit und Ergonomie erreichen wollten. Versuche es mit Rust und finde heraus, ob dessen Möglichkeiten für dich geeignet sind.

Für wen dieses Buch gedacht ist

In diesem Buch wird davon ausgegangen, dass du bereits Code in einer anderen Programmiersprache geschrieben hast, es spielt aber keine Rolle in welcher. Wir haben versucht, das Material einem breiten Publikum mit unterschiedlichem Programmierhintergrund zugänglich zu machen. Wir verbringen nicht viel Zeit damit, darüber zu sprechen, was Programmieren ist oder wie man darüber denkt. Wenn Programmieren für dich ganz neu ist, wäre es besser, wenn du ein Buch speziell zur Einführung in die Programmierung liest.

Wie man dieses Buch verwendet

Im Allgemeinen geht dieses Buch davon aus, dass du es der Reihe nach von vorne nach hinten liest. Spätere Kapitel bauen auf den Konzepten früherer Kapitel auf. Frühere Kapitel gehen möglicherweise nicht auf die Einzelheiten eines Themas ein, denn in der Regel werden wir es in einem späteren Kapitel erneut aufgreifen.

Du findest in diesem Buch zwei Kapitelarten: Konzeptkapitel und Projektkapitel. In Konzeptkapiteln erfährst du etwas über einen Aspekt von Rust. In Projektkapiteln schreiben wir gemeinsam kleine Programme und wenden das bisher Gelernte an. Die Kapitel 2, 12 und 20 sind Projektkapitel; die übrigen sind Konzeptkapitel.

Kapitel 1 erklärt, wie man Rust installiert, wie man ein „Hallo Welt“-Programm schreibt und wie man Cargo, den Paketmanager und das Bauwerkzeug von Rust, benutzt. Kapitel 2 ist eine praktische Einführung in die Sprache Rust. Hier werden Konzepte auf hohem Niveau behandelt, spätere Kapitel werden zusätzliche Einzelheiten liefern. Wenn du dir schon jetzt die Hände schmutzig machen willst, dann ist Kapitel 2 der richtige Ort dafür. Zunächst willst du vielleicht sogar Kapitel 3 überspringen, in dem es um Rust-Funktionen geht, die denen anderer Programmiersprachen ähneln, und direkt zu Kapitel 4 übergehen, um mehr über den Eigentümerschaftsansatz von Rust zu erfahren. Wenn du jedoch ein besonders akribischer Lerner bist, der lieber erst jedes Detail lernen will, bevor er zum nächsten übergeht, willst du vielleicht Kapitel 2 überspringen und direkt zu Kapitel 3 gehen und danach zu Kapitel 2 zurückkehren, um dann an einem Projekt zu arbeiten und die gelernten Details anzuwenden.

Kapitel 5 bespricht Strukturen und Methoden, und Kapitel 6 behandelt Aufzählungen, match-Ausdrücke und das if let-Kontrollflusskonstrukt. Du wirst Strukturen und Aufzählungen verwenden, um benutzerdefinierte Typen in Rust zu erstellen.

In Kapitel 7 erfährst du mehr über das Modulsystem von Rust und über die Datenschutzregeln zum Organisieren deines Codes und dessen öffentlich zugängliche Programmierschnittstelle (API). In Kapitel 8 werden einige gängige Kollektionsdatenstrukturen, die die Standardbibliothek zur Verfügung stellt, behandelt, z.B. Vektoren, Zeichenketten und Hashtabellen. Kapitel 9 befasst sich mit Rusts Philosophie und Techniken der Fehlerbehandlung.

Kapitel 10 vertieft generische Datentypen, Merkmale und Lebensdauern, die dir die Möglichkeit geben, Code zu schreiben, der für mehrere Typen passt. In Kapitel 11 dreht sich alles um das Testen, das selbst mit den Sicherheitsgarantien von Rust erforderlich ist, um eine korrekte Logik deines Programms sicherzustellen. In Kapitel 12 werden wir unsere eigene Implementierung für eine Teilfunktionalität des Kommandozeilenwerkzeugs grep schreiben, das nach Text in Dateien sucht. Dazu werden wir viele Konzepte anwenden, die wir in den vorangegangenen Kapiteln kennengelernt haben.

Kapitel 13 befasst sich mit Funktionsabschlüssen und Iteratoren, also Sprachmerkmalen, die von funktionalen Programmiersprachen stammen. In Kapitel 14 werden wir einen genaueren Blick auf Cargo werfen und über bewährte Vorgehensweisen beim Bereitstellen deiner Bibliotheken für andere sprechen. In Kapitel 15 werden intelligente Zeiger, die die Standardbibliothek bereitstellt, und Merkmale, die ihre Funktionalität ermöglichen, erörtert.

In Kapitel 16 gehen wir durch verschiedene Modelle der nebenläufigen Programmierung und sprechen darüber, wie Rust dir hilft, furchtlos mit mehreren Strängen zu programmieren. Kapitel 17 befasst sich mit dem Vergleich zwischen Rust-Idiomen und den Prinzipien der objektorientierten Programmierung, mit denen du vielleicht vertraut bist.

Kapitel 18 ist ein Nachschlagewerk zu Muster und Musterabgleich, einem mächtigen Mittel zum Ausdrücken von Ideen in Rust-Programmen. Kapitel 19 enthält ein Sammelsurium an interessanten fortgeschrittenen Themen, darunter unsicheres Rust, Makros und mehr zu Lebensdauer, Merkmalen, Typen, Funktionen und Funktionsabschlüssen.

In Kapitel 20 werden wir ein Projekt abschließen, bei dem wir einen systemnahen, nebenläufigen Webdienst implementieren!

Schließlich enthalten einige Anhänge nützliche Informationen über die Sprache in einem eher referenzartigen Format. Anhang A enthält die Schlüsselwörter von Rust, Anhang B die Operatoren und Symbole von Rust, Anhang C ableitbare Merkmalen, die von der Standardbibliothek mitgebracht werden, Anhang D nützliche Entwicklungswerkzeuge und Anhang E erläutert die Rust-Ausgaben. In Anhang F findest du Übersetzungen des Buches, und in Anhang G erfährst du, wie Rust erstellt wird und was nächtliches (nightly) Rust ist.

Es gibt keinen falschen Weg, dieses Buch zu lesen: Wenn du was überspringen willst, nur zu! Möglicherweise musst du zu früheren Kapiteln zurückkehren, wenn du irritiert bist. Aber tue, was immer für dich passt.

Ein wichtiger Teil beim Lernen von Rust ist das Verstehen der Fehlermeldungen, die der Compiler anzeigt: Diese leiten dich zum funktionierenden Code. Daher werden wir viele Beispiele bringen, die nicht kompilieren, zusammen mit der jeweiligen Fehlermeldung des Compilers. Wenn du also ein zufälliges Beispiel eingibst und ausführen willst, lässt es sich möglicherweise nicht kompilieren! Stelle sicher, dass du den umgebenden Text liest, um zu wissen, ob das Beispiel, das du ausführen willst, für einen Fehler gedacht ist. Ferris gibt dir einen Hinweis bei Code, der nicht funktionieren soll:

Ferris	Bedeutung
	Dieser Code lässt sich nicht kompilieren!
	Dieser Code bricht ab (panic)!
	Dieser Code liefert nicht das gewünschte Verhalten.

In den meisten Situationen führen wir dich zu einer funktionierenden Codeversion, wenn er sich nicht kompilieren lässt.

Quellcode

Die Quelldateien, aus denen dieses Buch generiert wird, findest du unter GitHub.

Erste Schritte

Lass uns mit Rust loslegen! Es gibt viel zu lernen, aber irgendwo muss man bekanntlich anfangen. In diesem Kapitel geht es um folgende Themen:

• Die Installation von Rust in Linux, macOS und Windows
• Das Schreiben eines Programms, das Hallo Welt! ausgibt
• Die Verwendung von cargo, Rusts Paketmanager und Bauwerkzeug

Installation

Der erste Schritt ist, Rust zu installieren. Wir werden Rust mittels rustup herunterladen, einem Kommandozeilenwerkzeug für die Verwaltung von Rust-Versionen und dazugehörigen Werkzeugen. Du wirst eine Internetverbindung für den Download benötigen.

Anmerkung: Falls du rustup aus irgendeinem Grund nicht verwenden möchtest, schaue bitte auf der Seite Andere Rust-Installationsmethoden nach anderen Möglichkeiten.

Die folgenden Schritte installieren die neueste stabile Version des Rust-Compilers. Rust garantiert Stabilität und stellt somit sicher, dass alle kompilierbaren Beispiele in diesem Buch auch mit neueren Rust-Versionen kompilierbar bleiben werden. Die Ausgabe der Beispiele kann sich zwischen Versionen leicht unterscheiden, weil Rust oft Fehlermeldungen und Warnungen verbessert. Anders ausgedrückt, jede neuere stabile Version von Rust, die du mithilfe dieser Schritte installierst, sollte wie erwartet mit dem Inhalt dieses Buchs funktionieren.

Kommandozeilen-Schreibweise

In diesem Kapitel und im ganzen Buch werden wir einige Befehle auf dem Terminal zeigen. Alle Zeilen, die du in das Terminal eingeben sollst, beginnen mit $. Du brauchst das $-Zeichen nicht einzugeben; es weist nur auf den Beginn jedes Befehls hin. Zeilen, die nicht mit $ beginnen, zeigen normalerweise die Ausgabe eines vorherigen Befehls. PowerShell-spezifische Beispiele werden außerdem > anstelle von $ verwenden.

Die Installation von rustup in Linux und macOS

Falls du Linux oder macOS verwendest, öffne ein Terminalfenster und gib den folgenden Befehl ein:

$ curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf | sh

Dieser Befehl lädt ein Skript herunter und startet die Installation von rustup, welches die neueste stabile Version von Rust installiert. Du wirst ggf. aufgefordert, dein Passwort einzugeben. Nach erfolgreicher Installation erscheint folgende Zeile:

Rust is installed now. Great!

Außerdem benötigst du einen Programmbinder (linker), ein Programm, das Rust verwendet, um die kompilierten Ausgaben in eine Datei zusammenzuführen. Wahrscheinlich hast du bereits einen. Wenn du Linker-Fehler erhältst, solltest du einen C-Compiler installieren, der in der Regel auch einen Linker enthält. Ein C-Compiler ist auch deshalb nützlich, weil einige gängige Rust-Pakete von C-Code abhängen und daher einen C-Compiler benötigen.

Unter macOS erhältst du einen C-Compiler, indem du folgendes ausführst:

$ xcode-select --install

Linux-Benutzer sollten in der Regel GCC oder Clang installieren, je nach Dokumentation ihrer Distribution. Wenn du zum Beispiel Ubuntu verwendest, kannst du das Paket build-essential installieren.

Die Installation von rustup in Windows

Rufe https://www.rust-lang.org/tools/install auf und folge den Anweisungen, um Rust in Windows zu installieren. Während der Installation wirst du eine Meldung erhalten, dass du auch die MSVC Bauwerkzeuge für Visual Studio 2013 oder höher benötigst.

Um die Bauwerkzeuge zu erhalten, musst du Visual Studio 2022 installieren. Wenn du gefragt wirst, welche Komponenten installiert werden sollen, gib folgendes an:

• „Desktop Development with C++“
• Das Windows 10 oder 11 SDK
• Das englische Sprachpaket zusammen mit einem beliebigen anderen Sprachpaket deiner Wahl.

Der Rest dieses Buchs verwendet Befehle, die sowohl in cmd.exe als auch in der PowerShell funktionieren. Falls es spezifische Unterschiede geben sollte, werden wir diese erläutern.

Fehlersuche

Um zu überprüfen, ob du Rust korrekt installiert hast, öffne ein Terminal und gib folgende Zeile ein:

$ rustc --version

Du solltest die Versionsnummer, den Commit-Hash und das Commit-Datum für die letzte stabile Version, die veröffentlicht wurde, in folgendem Format sehen:

rustc x.y.z (abcabcabc jjjj-mm-tt)

Wenn du diese Information siehst, hast du Rust erfolgreich installiert! Wenn du diese Information nicht siehst, überprüfe, ob Rust in deiner Systemvariable %PATH% wie folgt enthalten ist.

In Windows CMD verwende:

> echo %PATH%

In PowerShell verwende:

> echo $env:Path

In Linux und macOS verwende:

$ echo $PATH

Wenn das alles korrekt ist und Rust immer noch nicht funktioniert, gibt es mehrere Stellen, an denen du Hilfe bekommen kannst. Wie du mit anderen Rust-Entwicklern in Kontakt treten kannst, erfährst du auf der Gemeinschafts-Seite.

Aktualisieren und Deinstallieren

Nachdem du Rust mithilfe von rustup installiert hast, ist es einfach, auf die neueste Version zu aktualisieren. Führe folgenden Befehl im Terminal aus:

$ rustup update

Um Rust und rustup zu deinstallieren, führe folgenden Befehl aus:

$ rustup self uninstall

Lokale Dokumentation

Die Rust-Installation enthält auch eine lokale Kopie der Dokumentation, sodass du sie ohne Internetverbindung lesen kannst. Führe rustup doc aus, um die lokale Dokumentation in deinem Browser zu öffnen.

Falls du dir nicht sicher bist, wie du einen Typ oder eine Funktion aus der Standardbibliothek verwenden sollst, dann schau in der API-Dokumentation nach!

Hallo Welt

Nun, da du Rust installiert hast, lass uns dein erstes Rust-Programm schreiben. Wenn man eine neue Sprache lernt, ist es üblich, ein kleines Programm zu schreiben, das den Text Hallo Welt! auf dem Bildschirm ausgibt, also werden wir hier das gleiche tun!

Hinweis: Dieses Buch setzt grundlegende Vertrautheit mit der Kommandozeile voraus. Rust stellt keine besonderen Anforderungen an deine Textbearbeitung oder Werkzeuge oder an den Ort, an dem dein Code lebt. Wenn du also lieber eine integrierte Entwicklungsumgebung (IDE) statt der Kommandozeile verwenden möchtest, kannst du deine bevorzugte IDE verwenden. Viele IDEs bieten mittlerweile einen gewissen Grad an Rust-Unterstützung; Einzelheiten findest du in der Dokumentation der IDE. Das Rust-Team hat sich darauf konzentriert, eine großartige IDE-Unterstützung mittels rust-analyzer zu ermöglichen. Siehe Anhang D für weitere Details.

Erstellen eines Projektverzeichnisses

Du beginnst damit, ein Verzeichnis zum Speichern deines Rust-Codes zu erstellen. Es ist Rust egal, wo dein Code lebt, aber für die Übungen und Projekte in diesem Buch schlagen wir vor, ein Verzeichnis projects in deinem Hauptverzeichnis anzulegen und all deine Projekte dort abzulegen.

Öffne ein Terminal und gib die folgenden Befehle ein, um ein Verzeichnis projects und ein Verzeichnis für das Projekt „Hallo Welt!“ innerhalb des Verzeichnisses projects zu erstellen.

Gib dies bei Linux, macOS und PowerShell unter Windows ein:

$ mkdir ~/projects
$ cd ~/projects
$ mkdir hello_world
$ cd hello_world

Bei Windows CMD gib dies ein:

> mkdir "%USERPROFILE%\projects"
> cd /d "%USERPROFILE%\projects"
> mkdir hello_world
> cd hello_world

Schreiben und Ausführen eines Rust-Programms

Als nächstes erstelle eine neue Quelldatei und nenne sie main.rs. Rust-Dateien enden immer mit der Erweiterung .rs. Wenn du mehr als ein Wort in deinem Dateinamen verwendest, verwende einen Unterstrich, um sie zu trennen. Verwende zum Beispiel hello_world.rs statt helloworld.rs.

Öffne nun die Datei main.rs, die du gerade erstellt hast, und gib den Code in Codeblock 1-1 ein.

Dateiname: main.rs

fn main() {
    println!("Hallo Welt!");
}

Codeblock 1-1: Ein Programm, das Hallo Welt! ausgibt

Speichere die Datei und gehe zurück zu deinem Terminalfenster im Verzeichnis ~/projects/hello_world. Gib unter Linux oder MacOS die folgenden Befehle ein, um die Datei zu kompilieren und auszuführen:

$ rustc main.rs
$ ./main
Hallo Welt!

Unter Windows gib den Befehl .\main.exe anstelle von ./main ein:

> rustc main.rs
> .\main.exe
Hallo Welt!

Unabhängig von deinem Betriebssystem sollte die Zeichenfolge Hallo Welt! im Terminal ausgegeben werden. Wenn du diese Ausgabe nicht siehst, lies im Abschnitt „Fehlersuche“ des Installationsabschnitts nach, wie du Hilfe erhalten kannst.

Wenn Hallo Welt! ausgegeben wurde, herzlichen Glückwunsch! Du hast offiziell ein Rust-Programm geschrieben. Das macht dich zu einem Rust-Programmierer – willkommen!

Anatomie eines Rust-Programms

Lass uns im Detail Revue passieren, was gerade in deinem „Hallo Welt!“-Programm passiert ist. Hier ist das erste Teil des Puzzles:

fn main() {

}

Diese Zeilen definieren eine Funktion namens main in Rust. Die Funktion main ist eine Besonderheit: Sie ist immer der erste Code, der in jedem ausführbaren Rust-Programm ausgeführt wird. In diesem Fall deklariert die erste Zeile eine Funktion mit dem namen main, die keine Parameter hat und nichts zurückgibt. Wenn es Parameter gäbe, würden sie innerhalb der Klammern () stehen.

Der Funktionsrumpf in geschweifte Klammern {} eingehüllt. Rust erfordert diese um alle Funktionsrümpfe. Es ist guter Stil, die öffnende geschweifte Klammer in dieselbe Zeile wie die Funktionsdeklaration zu platzieren und dazwischen ein Leerzeichen einzufügen.

Hinweis: Wenn du einen Standardstil für alle Rust-Projekte verwenden möchtest, kannst du ein automatisches Formatierungswerkzeug namens rustfmt verwenden, um deinen Code in einem bestimmten Stil zu formatieren (mehr über rustfmt im Anhang D). Das Rust-Team hat dieses Tool wie rustc in die Standard-Rust-Distribution aufgenommen, es sollte also bereits auf deinem Computer installiert sein!

Innerhalb der Funktion main befindet sich der folgende Code:

#![allow(unused)]
fn main() {
    println!("Hallo Welt!");
}

Diese Zeile erledigt die ganze Arbeit in diesem kleinen Programm: Sie gibt Text auf dem Bildschirm aus. Hier gibt es vier wichtige Details zu beachten.

Erstens wird im Rust-Stil mit vier Leerzeichen eingerückt, nicht mit einem Tabulator.

Zweitens ruft println! ein Rust-Makro auf. Wenn es stattdessen eine Funktion aufrufte, würde diese als println (ohne !) angegeben werden. Wir werden die Rust-Makros in Kapitel 19 ausführlicher besprechen. Im Moment musst du nur wissen, dass die Verwendung eines ! bedeutet, dass du ein Makro anstelle einer normalen Funktion aufrufst und dass Makros nicht immer denselben Regeln folgen wie Funktionen.

Drittens siehst du die Zeichenkette "Hallo Welt!". Wir übergeben diese Zeichenkette als Argument an println!, und die Zeichenkette wird auf dem Bildschirm ausgegeben.

Viertens beenden wir die Zeile mit einem Semikolon (;), was anzeigt, dass dieser Ausdruck beendet ist und der nächste beginnen kann. Die meisten Zeilen eines Rust-Codes enden mit einem Semikolon.

Kompilieren und Ausführen sind getrennte Schritte

Du hast gerade ein neu erstelltes Programm ausgeführt, also lass uns jeden Schritt in diesem Prozess untersuchen.

Bevor du ein Rust-Programm ausführst, musst du es mit dem Rust-Compiler kompilieren, indem du den Befehl rustc eingibst und ihm den Namen deiner Quelldatei übergibst, so wie hier:

$ rustc main.rs

Wenn du einen C- oder C++-Hintergrund hast, wirst du feststellen, dass dies ähnlich wie gcc oder clang ist. Nach erfolgreicher Kompilierung gibt Rust eine ausführbare Binärdatei aus.

Unter Linux, MacOS und PowerShell unter Windows kannst du die ausführbare Datei sehen, indem du den Befehl ls in deinem Terminal eingibst:

$ ls
main  main.rs

Unter Linux und MacOS siehst du zwei Dateien. Mit PowerShell unter Windows siehst du die gleichen drei Dateien, die du mit CMD sehen würdest. Bei CMD unter Windows würdest du folgendes eingeben:

> dir /B %= die Option /B bewirkt, dass nur die Dateinamen angezeigt werden =%
main.exe
main.pdb
main.rs

Dies zeigt die Quellcodedatei mit der Erweiterung .rs, die ausführbare Datei (main.exe unter Windows, aber main auf allen anderen Plattformen) und, bei Verwendung von Windows, eine Datei mit Debugging-Informationen mit der Erweiterung .pdb. Von hier aus führst du die Datei main oder main.exe aus, so wie hier:

$ ./main # oder .\main.exe unter Windows

Wenn main.rs dein „Hallo Welt!“-Programm wäre, würde diese Zeile „Hallo Welt!“ in deinem Terminal ausgeben.

Wenn du mit einer dynamischen Sprache wie Ruby, Python oder JavaScript besser vertraut bist, bist du es möglicherweise nicht gewohnt, ein Programm in getrennten Schritten zu kompilieren und auszuführen. Rust ist eine vorab kompilierte (ahead-of-time compiled) Sprache, d.h. du kannst ein Programm kompilieren und die ausführbare Datei an jemand anderen weitergeben, und dieser kann das Programm auch ohne Installation von Rust ausführen. Wenn du jemandem eine .rb-, .py- oder .js-Datei gibst, muss er eine Ruby-, Python- bzw. JavaScript-Implementierung installiert haben. Aber in diesen Sprachen benötigst du nur einen Befehl, um dein Programm zu kompilieren und auszuführen. Beim Sprachdesign ist alles ein Kompromiss.

Einfach mit rustc zu kompilieren ist für einfache Programme in Ordnung, aber wenn dein Projekt wächst, wirst du alle Optionen verwalten und es einfach machen wollen, deinen Code weiterzugeben. Als Nächstes stellen wir dir das Cargo-Tool vor, das dir beim Schreiben von Rust-Programmen aus der realen Welt helfen wird.

Hallo Cargo

Cargo ist das Bau-System (build system) und der Paketmanager von Rust. Die meisten Rust-Entwickler verwenden dieses Werkzeug, um ihre Rust-Projekte zu verwalten, weil Cargo viele Aufgaben für dich erledigt, z.B. Bauen deines Codes, Herunterladen der Bibliotheken, von denen dein Code abhängt, und das Bauen dieser Bibliotheken. (Wir nennen Bibliotheken, die dein Code benötigt, Abhängigkeiten (dependencies).)

Die einfachsten Rust-Programme, wie das, das wir bisher geschrieben haben, haben keine Abhängigkeiten. Wenn wir also das „Hallo Welt!“-Projekt mit Cargo gebaut hätten, würde es nur den Teil von Cargo verwenden, der für das Bauen deines Codes zuständig ist. Wenn du komplexere Rust-Programme schreibst, wirst du Abhängigkeiten hinzufügen, und wenn du ein Projekt mit Cargo beginnst, wird das Hinzufügen von Abhängigkeiten viel einfacher sein.

Da die überwiegende Mehrheit der Rust-Projekte Cargo verwendet, geht der Rest dieses Buches davon aus, dass auch du Cargo verwendest. Cargo wird mit Rust installiert, wenn du die offiziellen Installationsprogramme verwendet hast, die im Abschnitt „Installation“ besprochen werden. Wenn du Rust auf eine andere Weise installiert hast, prüfe, ob Cargo installiert ist, indem du Folgendes in dein Terminal eingibst:

$ cargo --version

Wenn du eine Versionsnummer siehst, hast du es! Wenn du einen Fehler siehst, z.B. command not found, schaue in der Dokumentation zu deiner Installationsmethode nach, um festzustellen, wie du Cargo separat installieren kannst.

Projekt mit Cargo erstellen

Lass uns mit Cargo ein neues Projekt erstellen und uns ansehen, wie es sich von unserem ursprünglichen „Hallo Welt!“-Projekt unterscheidet. Navigiere zurück zu deinem projects-Verzeichnis (oder wo auch immer du dich entschieden hast, deinen Code zu speichern). Führe dann auf einem beliebigen Betriebssystem die folgenden Schritte aus:

$ cargo new hello_cargo
$ cd hello_cargo

Der erste Befehl erstellt ein neues Verzeichnis und ein Projekt namens hello_cargo. Wir haben unser Projekt hello_cargo genannt und Cargo erstellt seine Dateien in einem Verzeichnis mit demselben Namen.

Gehe in das Verzeichnis hello_cargo und liste die Dateien auf. Du wirst sehen, dass Cargo zwei Dateien und ein Verzeichnis für uns generiert hat: Eine Datei Cargo.toml und ein Verzeichnis src mit einer Datei main.rs darin.

Es hat auch ein neues Git-Repository zusammen mit einer Datei .gitignore initialisiert. Git-Dateien werden nicht erzeugt, wenn du cargo new innerhalb eines existierenden Git-Repositories ausführst; du kannst dieses Verhalten überschreiben, indem du cargo new --vcs=git verwendest.

Hinweis: Git ist ein gebräuchliches Versionskontrollsystem. Du kannst cargo new anpassen, um ein anderes Versionskontrollsystem oder kein Versionskontrollsystem zu verwenden, indem du das Flag --vcs verwendest. Führe cargo new --help aus, um die verfügbaren Optionen zu sehen.

Öffne Cargo.toml in einem Texteditor deiner Wahl. Es sollte ähnlich wie der Code in Codeblock 1-2 aussehen.

Dateiname: Cargo.toml

[package]
name = "hello_cargo"
version = "0.1.0"
edition = "2021"

# Weitere Schlüssel und ihre Definitionen findest du unter
# https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

Codeblock 1-2: Inhalt von Cargo.toml erzeugt durch cargo new

Diese Datei liegt im Format TOML (Tom's Obvious, Minimal Language) vor, welches das Konfigurationsformat von Cargo ist.

Die erste Zeile [package] ist eine Abschnittsüberschrift, die anzeigt, dass die folgenden Anweisungen ein Paket konfigurieren. Wenn wir weitere Informationen zu dieser Datei hinzufügen, werden wir weitere Abschnitte hinzufügen.

Die nächsten drei Zeilen legen die Konfigurationsinformationen fest, die Cargo benötigt, um dein Programm zu kompilieren: Den Namen, die Version und die zu verwendende Rust-Ausgabe. Über den Schlüssel edition sprechen wir in Anhang E.

Die letzte Zeile [dependencies] ist der Anfang eines Abschnitts, in dem du alle Abhängigkeiten deines Projekts auflisten kannst. In Rust werden Code-Pakete als Kisten (crates) bezeichnet. Wir werden keine anderen Kisten für dieses Projekt benötigen, aber wir werden es im ersten Projekt in Kapitel 2 tun, also werden wir dann diesen Abhängigkeits-Abschnitt verwenden.

Öffne nun src/main.rs und wirf einen Blick darauf:

Dateiname: src/main.rs

fn main() {
    println!("Hello, world!");
}

Cargo hat für dich ein „Hello, world!“-Programm generiert, genau wie das, das wir in Codeblock 1-1 geschrieben haben! Die Unterschiede zwischen unserem Projekt und dem Projekt, das Cargo generiert hat, bestehen bisher darin, dass Cargo den Code im Verzeichnis src abgelegt hat, und wir haben eine Konfigurationsdatei Cargo.toml im obersten Verzeichnis.

Cargo erwartet, dass deine Quelldateien innerhalb des src-Verzeichnisses liegen. Das Projektverzeichnis der obersten Ebene ist nur für README-Dateien, Lizenzinformationen, Konfigurationsdateien und alles andere, was nicht mit deinem Code zusammenhängt. Das Verwenden von Cargo hilft dir, deine Projekte zu organisieren. Es gibt einen Platz für alles und alles ist an seinem Platz.

Wenn du ein Projekt begonnen hast, das Cargo nicht verwendet, wie wir es mit dem Projekt „Hallo Welt!“ getan haben, kannst du es in ein Projekt umwandeln, das Cargo verwendet. Verschiebe den Projektcode in das Verzeichnis src und erstelle eine entsprechende Cargo.toml-Datei.

Bauen und Ausführen eines Cargo-Projekts

Schauen wir uns nun an, was anders ist, wenn wir das „Hello, world!“-Programm mit Cargo bauen und ausführen. Von deinem hello_cargo-Verzeichnis aus baust du dein Projekt, indem du den folgenden Befehl eingibst:

$ cargo build
   Compiling hello_cargo v0.1.0 (file:///projects/hello_cargo)
    Finished dev [unoptimized + debuginfo] target(s) in 2.85 secs

Dieser Befehl erzeugt eine ausführbare Datei in target/debug/hello_cargo (oder target\debug\hello_cargo.exe unter Windows) und nicht in deinem aktuellen Verzeichnis. Da standardmäßig für den Debug-Modus gebaut wird, legt Cargo die Binärdatei in einem Verzeichnis namens debug ab. Mit diesem Befehl kannst du die ausführbare Datei ausführen:

$ ./target/debug/hello_cargo # oder .\target\debug\hello_cargo.exe unter Windows
Hello, world!

Wenn alles gut geht, sollte Hello, world! im Terminal ausgegeben werden. Wenn cargo build zum ersten Mal ausgeführt wird, erzeugt Cargo auch eine neue Datei auf der obersten Ebene: Cargo.lock. Diese Datei verfolgt die genauen Versionen der Abhängigkeiten in deinem Projekt. Dieses Projekt hat keine Abhängigkeiten, daher ist die Datei etwas spärlich. Du musst diese Datei niemals manuell ändern; Cargo verwaltet ihren Inhalt für dich.

Wir haben gerade ein Projekt mit cargo build gebaut und es mit ./target/debug/hello_cargo ausgeführt, aber wir können auch cargo run verwenden, um den Code zu kompilieren und dann die resultierende ausführbare Datei mit einem einzigen Befehl auszuführen:

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/hello_cargo`
Hello, world!

Das Verwenden von cargo run ist bequemer, als sich daran erinnern zu müssen, cargo build auszuführen und dann den gesamten Pfad zur Binärdatei zu verwenden, daher verwenden die meisten Entwickler cargo run.

Beachte, dass wir diesmal keine Ausgabe gesehen haben, die darauf hinweist, dass Cargo hello_cargo kompiliert hat. Cargo fand heraus, dass sich die Dateien nicht geändert hatten, also hat es nicht neu gebaut, sondern ließ einfach die Binärdatei laufen. Wenn du deinen Quellcode geändert hättest, hätte Cargo das Projekt vor der Ausführung neu kompiliert, und du hättest diese Ausgabe gesehen:

$ cargo run
   Compiling hello_cargo v0.1.0 (file:///projects/hello_cargo)
    Finished dev [unoptimized + debuginfo] target(s) in 0.33 secs
     Running `target/debug/hello_cargo`
Hello, world!

Cargo bietet auch einen Befehl namens cargo check. Dieser Befehl überprüft schnell deinen Code, um sicherzustellen, dass er kompiliert, erzeugt aber keine ausführbare Datei:

$ cargo check
   Checking hello_cargo v0.1.0 (file:///projects/hello_cargo)
    Finished dev [unoptimized + debuginfo] target(s) in 0.32 secs

Warum willst du keine ausführbare Datei? Häufig ist cargo check viel schneller als cargo build, weil es den Schritt der Erstellung einer ausführbaren Datei überspringt. Wenn du deine Arbeit während des Schreibens des Codes ständig überprüfst, wird das Verwenden von cargo check den Prozess beschleunigen! Daher führen viele Rust-Entwickler während des Schreibens ihres Programms regelmäßig cargo check aus, um sicherzustellen, dass das Programm kompiliert. Dann lassen sie cargo build laufen, wenn sie bereit sind, die ausführbare Datei zu benutzen.

Lasse uns zusammenfassen, was wir bisher über Cargo gelernt haben:

• Wir können ein Projekt mit cargo new erstellen.
• Wir können ein Projekt mit cargo build bauen.
• Wir können ein Projekt mit cargo run in einem Schritt bauen und ausführen.
• Wir können ein Projekt mit cargo check bauen, ohne eine Binärdatei zu erzeugen, um auf Fehler zu prüfen.
• Anstatt das Ergebnis des Bauvorgangs im selben Verzeichnis wie unser Code abzulegen, legt Cargo es im Verzeichnis target/debug ab.

Ein zusätzlicher Vorteil der Verwendung von Cargo ist, dass die Befehle unabhängig vom Betriebssystem sind, mit dem du arbeitest. Daher werden wir an dieser Stelle keine spezifischen Anweisungen für Linux und macOS gegenüber Windows mehr geben.

Bauen einer Freigabe (release)

Wenn dein Projekt schließlich zur Freigabe bereit ist, kannst du cargo build --release verwenden, um es mit Optimierungen zu kompilieren. Dieser Befehl erzeugt eine ausführbare Datei in target/release anstelle von target/debug. Durch die Optimierungen läuft dein Rust-Code schneller, aber wenn du sie einschaltest, verlängert sich die Zeit, die dein Programm zum Kompilieren benötigt. Aus diesem Grund gibt es zwei verschiedene Profile: Eines für die Entwicklung, wenn du schnell und oft neu bauen willst, und ein anderes für das Erstellen des endgültigen Programms, das du einem Benutzer gibst, das nicht wiederholt neu gebaut wird und das so schnell wie möglich läuft. Wenn du einen Laufzeit-Benchmark deines Codes durchführst, stelle sicher, dass du cargo build --release ausführst und den Benchmark mit der ausführbaren Datei in target/release durchführst.

Cargo als Konvention

Bei einfachen Projekten bietet Cargo nicht viel mehr Wert als das bloße Verwenden von rustc, aber es wird sich in dem Maße bewähren, wie deine Programme immer komplizierter werden. Sobald Programme auf mehrere Dateien anwachsen oder eine Abhängigkeit benötigen, ist es viel einfacher, Cargo den Bauvorgang koordinieren zu lassen.

Auch wenn das Projekt hello_cargo einfach ist, so verwendet es jetzt einen Großteil der realen Werkzeuge, die du im Rest deiner Rust-Karriere verwenden wirst. Tatsächlich kannst du, um an bestehenden Projekten zu arbeiten, die folgenden Befehle verwenden, um den Code mit Git auszuchecken, in das Verzeichnis dieses Projekts zu wechseln und zu bauen:

$ git clone example.org/someproject
$ cd someproject
$ cargo build

Weitere Informationen über Cargo findest du unter seiner Dokumentation.

Zusammenfassung

Du hast deine Rust-Reise bereits gut begonnen! In diesem Kapitel hast du gelernt, wie es geht:

• Installiere die neueste stabile Version von Rust mit rustup.
• Aktualisiere auf eine neuere Rust-Version.
• Öffne die lokal installierte Dokumentation.
• Schreibe und führe ein „Hallo Welt!“-Programm aus, direkt mittels rustc.
• Schreibe und führe ein neues Projekt aus mittels Cargo-Konventionen.

Dies ist ein guter Zeitpunkt, ein umfangreicheres Programm zu erstellen, um sich an das Lesen und Schreiben von Rust-Code zu gewöhnen. In Kapitel 2 werden wir also ein Ratespielprogramm erstellen. Wenn du lieber damit beginnen möchtest, zu lernen, wie gängige Programmierkonzepte in Rust funktionieren, lies Kapitel 3 und kehre dann zu Kapitel 2 zurück.

Ein Ratespiel programmieren

Lass uns den Sprung in Rust wagen, indem wir gemeinsam ein praktisches Projekt durcharbeiten! Dieses Kapitel führt dich in einige gängige Rust-Konzepte ein, indem es dir zeigt, wie du diese in einem realen Programm verwenden kannst. Du lernst let, match, Methoden, assoziierte Funktionen, externe Kisten (crates) und mehr kennen! In den folgenden Kapiteln werden wir diese Ideen ausführlicher behandeln. In diesem Kapitel wirst du nur die Grundlagen üben.

Wir werden ein klassisches Programmierproblem für Anfänger implementieren: Ein Ratespiel. Und so funktioniert es: Das Programm erzeugt eine zufällige ganze Zahl zwischen 1 und 100. Dann wird es den Spieler auffordern, eine Schätzung einzugeben. Nachdem eine Schätzung eingegeben wurde, zeigt das Programm an, ob die Schätzung zu niedrig oder zu hoch ist. Wenn die Schätzung korrekt ist, gibt das Spiel eine Glückwunschnachricht aus und beendet sich.

Aufsetzen eines neuen Projekts

Um ein neues Projekt aufzusetzen, gehe in das Verzeichnis projects, das du in Kapitel 1 erstellt hast, und erstelle ein neues Projekt mit Cargo, wie folgt:

$ cargo new guessing_game
$ cd guessing_game

Der erste Befehl cargo new nimmt den Namen des Projekts (guessing_game) als erstes Argument. Der zweite Befehl wechselt in das Verzeichnis des neuen Projekts.

Schaue dir die generierte Datei Cargo.toml an:

Dateiname: Cargo.toml

[package]
name = "guessing_game"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

Wie du in Kapitel 1 gesehen hast, generiert cargo new ein „Hello, world!“-Programm für dich. Sieh dir die Datei src/main.rs an:

Dateiname: src/main.rs

fn main() {
    println!("Hello, world!");
}

Kompilieren wir nun dieses „Hello, world!“-Programm und führen es im gleichen Schritt aus mit dem Befehl cargo run:

$ cargo run
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished dev [unoptimized + debuginfo] target(s) in 1.50s
     Running `target/debug/guessing_game`
Hello, world!

Der Befehl run ist praktisch, wenn du ein Projekt schnell iterieren musst, wie wir es in diesem Spiel tun werden, indem du jede Iteration schnell testest, bevor du zur nächsten übergehst.

Öffne die Datei src/main.rs erneut. Du wirst den gesamten Code in diese Datei schreiben.

Verarbeiten einer Schätzung

Der erste Teil des Ratespielprogramms fragt nach einer Benutzereingabe, verarbeitet diese Eingabe und überprüft, ob die Eingabe in der erwarteten Form vorliegt. Zu Beginn erlauben wir dem Spieler, eine Schätzung einzugeben. Gib den Code aus Codeblock 2-1 in src/main.rs ein.

Dateiname: src/main.rs

use std::io;

fn main() {
    println!("Rate die Zahl!");

    println!("Bitte gib deine Schätzung ein.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Fehler beim Lesen der Zeile");

    println!("Du hast geschätzt: {guess}");
}

Codeblock 2-1: Code, der eine Schätzung vom Benutzer erhält und ausgibt

Dieser Code enthält eine Menge Informationen, also gehen wir ihn Zeile für Zeile durch. Um eine Benutzereingabe zu erhalten und das Ergebnis dann als Ausgabe auszugeben, müssen wir die Bibliothek io (input/output) in den Gültigkeitsbereich bringen. Die io-Bibliothek stammt aus der Standardbibliothek, bekannt als std:

use std::io;

fn main() {
    println!("Rate die Zahl!");

    println!("Bitte gib deine Schätzung ein.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Fehler beim Lesen der Zeile");

    println!("Du hast geschätzt: {guess}");
}

Standardmäßig hat Rust einige Elemente in der Standardbibliothek definiert, die es in den Gültigkeitsbereich jedes Programms bringt. Diese Menge wird Präludium genannt, und du kannst deren Inhalt in der Dokumentation der Standardbibliothek sehen.

Wenn ein Typ, den du verwenden willst, nicht im Präludium enthalten ist, musst du diesen Typ explizit mit einer use-Anweisung in den Gültigkeitsbereich bringen. Das Verwenden der Bibliothek std::io bietet dir eine Reihe von nützlichen Funktionalitäten, einschließlich der Möglichkeit, Benutzereingaben entgegenzunehmen.

Wie du in Kapitel 1 gesehen hast, ist die Funktion main der Einstiegspunkt in das Programm:

use std::io;

fn main() {
    println!("Rate die Zahl!");

    println!("Bitte gib deine Schätzung ein.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Fehler beim Lesen der Zeile");

    println!("Du hast geschätzt: {guess}");
}

Die Syntax fn deklariert eine neue Funktion; die Klammern () zeigen an, dass es keine Parameter gibt; und die geschweifte Klammer { beginnt den Rumpf der Funktion.

Wie du auch in Kapitel 1 gelernt hast, ist println! ein Makro, das eine Zeichenkette auf dem Bildschirm ausgibt:

use std::io;

fn main() {
    println!("Rate die Zahl!");

    println!("Bitte gib deine Schätzung ein.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Fehler beim Lesen der Zeile");

    println!("Du hast geschätzt: {guess}");
}

Dieser Code gibt eine Eingabeaufforderung aus, die angibt, um was für ein Spiel es sich handelt, und den Benutzer zur Eingabe auffordert.

Speichern von Werten mit Variablen

Als Nächstes erstellen wir eine Variable, um die Benutzereingabe zu speichern, wie hier:

use std::io;

fn main() {
    println!("Rate die Zahl!");

    println!("Bitte gib deine Schätzung ein.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Fehler beim Lesen der Zeile");

    println!("Du hast geschätzt: {guess}");
}

Jetzt wird das Programm interessant! Es ist viel los in dieser kleinen Zeile. Wir verwenden eine let-Anweisung, um eine Variable zu erzeugen. Hier ist ein weiteres Beispiel:

let apples = 5;

Diese Zeile erzeugt eine neue Variable namens apples und bindet sie an den Wert 5. In Rust sind Variablen standardmäßig unveränderbar (immutable), das heißt, sobald wir der Variablen einen Wert gegeben haben, wird sich der Wert nicht mehr ändern. Wir werden dieses Konzept im Abschnitt „Variablen und Veränderbarkeit“ in Kapitel 3 ausführlich besprechen. Um eine Variable veränderbar zu machen, ergänzen wir mut vor dem Variablennamen:

#![allow(unused)]
fn main() {
let apples = 5; // unveränderbar
let mut bananas = 5; // veränderbar
}

Anmerkung: Die Syntax // beginnt einen Kommentar, der bis zum Ende der Zeile weitergeht. Rust ignoriert alles in Kommentaren. Diese werden in Kapitel 3 ausführlicher besprochen.

Zurück zum Programm des Ratespiels. Du weißt jetzt, dass let mut guess eine veränderbare Variable namens guess einführt. Das Gleichheitszeichen (=) sagt Rust, dass wir jetzt etwas an die Variable binden wollen. Auf der rechten Seite des Gleichheitszeichens steht der Wert, an den guess gebunden ist, was das Ergebnis des Aufrufs von String::new ist, einer Funktion, die eine neue Instanz eines String zurückgibt. String ist ein von der Standardbibliothek bereitgestellter Zeichenketten-Typ, der ein wachstumsfähiges, UTF-8-kodiertes Stück Text ist.

Die Syntax :: in der Zeile ::new zeigt an, dass new eine assoziierte Funktion (associated function) vom Typ String ist. Eine assoziierte Funktion ist eine Funktion, die auf einem Typ, in diesem Fall String, implementiert ist. Diese Funktion new erzeugt eine neue, leere Zeichenkette. Du wirst eine Funktion new bei vielen Typen finden, weil es ein gebräuchlicher Name für eine Funktion ist, die einen neuen Wert irgendeiner Art erzeugt.

Insgesamt hat die Zeile let mut guess = String::new(); eine veränderbare Variable erzeugt, die derzeit an eine neue, leere Instanz eines String gebunden ist. Uff!

Empfangen von Benutzereingaben

Erinnere dich, dass wir die Ein-/Ausgabefunktionalität aus der Standardbibliothek mit use std::io; in der ersten Zeile des Programms eingebunden haben. Jetzt rufen wir die Funktion stdin aus dem Modul io auf, die es uns ermöglichen wird, Benutzereingaben zu verarbeiten.

use std::io;

fn main() {
    println!("Rate die Zahl!");

    println!("Bitte gib deine Schätzung ein.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Fehler beim Lesen der Zeile");

    println!("Du hast geschätzt: {guess}");
}

Hätten wir die Bibliothek io nicht am Anfang des Programms mit use std::io; importiert, könnten wir die Funktion trotzdem verwenden, indem wir den Funktionsaufruf als std::io::stdin schreiben. Die Funktion stdin gibt eine Instanz von std::io::Stdin zurück, was ein Typ ist, der eine Standardeingaberessource (handle to the standard input) für dein Terminal darstellt.

Die nächste Zeile .read_line(&mut guess) ruft die Methode read_line der Standardeingaberessource auf, um eine Eingabe vom Benutzer zu erhalten. Wir übergeben auch das Argument &mut guess an read_line, um ihm mitzuteilen, in welche Zeichenfolge es die Benutzereingabe speichern soll. Die Aufgabe von read_line ist es, alles, was der Benutzer in die Standardeingabe eingibt, an eine Zeichenkette anzuhängen (ohne deren Inhalt zu überschreiben), daher übergeben wir diese Zeichenkette als Argument. Das Zeichenketten-Argument muss veränderbar sein, damit die Methode den Inhalt der Zeichenkette ändern kann.

Das & zeigt an, dass es sich bei diesem Argument um eine Referenz handelt, die dir eine Möglichkeit bietet, mehrere Teile deines Codes auf einen Datenteil zugreifen zu lassen, ohne dass du diese Daten mehrfach in den Speicher kopieren musst. Referenzen sind eine komplexe Funktionalität, und einer der Hauptvorteile von Rust ist, wie sicher und einfach es ist, Referenzen zu verwenden. Du musst nicht viele dieser Details kennen, um dieses Programm fertigzustellen. Im Moment musst du nur wissen, dass Referenzen wie Variablen standardmäßig unveränderbar sind. Daher musst du &mut guess anstatt &guess schreiben, um sie veränderbar zu machen. (In Kapitel 4 werden Referenzen ausführlicher erklärt.)

Behandeln potentieller Fehler mit Result

Wir arbeiten noch immer an dieser Codezeile. Wir besprechen jetzt eine dritte Textzeile, aber beachte, dass sie immer noch Teil einer einzigen logischen Codezeile ist. Der nächste Teil ist diese Methode:

use std::io;

fn main() {
    println!("Rate die Zahl!");

    println!("Bitte gib deine Schätzung ein.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Fehler beim Lesen der Zeile");

    println!("Du hast geschätzt: {guess}");
}

Wir hätten diesen Code auch so schreiben können:

io::stdin().read_line(&mut guess).expect("Fehler beim Lesen der Zeile");

Eine lange Zeile ist jedoch schwer zu lesen, daher ist es am besten, sie aufzuteilen. Es ist oft ratsam, einen Zeilenumbruch und andere Leerzeichen einzufügen, um lange Zeilen aufzubrechen, wenn du eine Methode mit der Syntax .method_name() aufrufst. Lass uns nun besprechen, was diese Zeile bewirkt.

Wie bereits erwähnt, schreibt read_line die Benutzereingabe in die übergebene String-Variable, gibt aber darüber hinaus auch einen Result-Wert zurück. Result ist eine Aufzählung (enumeration, oder kurz enum), die einen Datentyp darstellt, der einem von mehreren möglichen Zuständen annehmen kann. Wir nennen jeden möglichen Zustand eine Variante.

In Kapitel 6 werden Aufzählungen ausführlicher behandelt. Der Zweck dieser Result-Typen ist es, Informationen zur Fehlerbehandlung zu kodieren.

Die Varianten von Result sind Ok und Err. Die Variante Ok gibt an, dass die Operation erfolgreich war, und der erfolgreich generierte Wert innerhalb von Ok steht. Die Variante Err bedeutet, dass die Operation fehlgeschlagen ist, und Err enthält Informationen darüber, wie oder warum die Operation fehlgeschlagen ist.

Für Werte vom Typ Result sind, wie für Werte jedes Typs, Methoden definiert. Eine Instanz von Result hat eine Methode expect, die du aufrufen kannst. Wenn diese io::Result-Instanz ein Err-Wert ist, wird expect das Programm zum Absturz bringen und die Meldung anzeigen, die du als Argument an expect übergeben hast. Wenn die Methode read_line ein Err zurückgibt, ist dies wahrscheinlich das Ergebnis eines Fehlers, der vom zugrundeliegenden Betriebssystem herrührt. Wenn diese io::Result-Instanz ein Ok-Wert ist, wird expect den Wert, den Ok hält, als Rückgabewert verwenden, damit du ihn verwenden kannst. In diesem Fall ist dieser Wert die Anzahl der Bytes, die der Benutzer in die Standardeingabe eingegeben hat.

Wenn du nicht expect aufrufst, wird das Programm kompiliert, aber du erhältst eine Warnung:

$ cargo build
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
warning: unused `Result` that must be used
  --> src/main.rs:10:5
   |
10 |     io::stdin().read_line(&mut guess);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this `Result` may be an `Err` variant, which should be handled
   = note: `#[warn(unused_must_use)]` on by default
help: use `let _ = ...` to ignore the resulting value
   |
10 |     let _ = io::stdin().read_line(&mut guess);
   |     +++++++

warning: `guessing_game` (bin "guessing_game") generated 1 warning
    Finished dev [unoptimized + debuginfo] target(s) in 0.59s

Rust warnt, dass du den von read_line zurückgegebenen Result-Wert nicht verwendet hast, was darauf hinweist, dass das Programm einen möglichen Fehler nicht behandelt hat.

Der richtige Weg, die Warnung zu unterdrücken, ist eine Fehlerbehandlung zu schreiben, aber da wir dieses Programm einfach nur abstürzen lassen wollen, wenn ein Problem auftritt, können wir expect verwenden. In Kapitel 9 erfährst du, wie man sich von Fehlern erholt.

Ausgeben von Werten mit println!-Platzhaltern

Abgesehen von der schließenden geschweiften Klammer gibt es in dem bisher hinzugefügten Code nur noch eine weitere Zeile zu besprechen:

use std::io;

fn main() {
    println!("Rate die Zahl!");

    println!("Bitte gib deine Schätzung ein.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Fehler beim Lesen der Zeile");

    println!("Du hast geschätzt: {guess}");
}

Diese Zeile gibt die Zeichenkette aus, die jetzt die Eingabe des Benutzers enthält. Der Satz geschweifte Klammern {} ist ein Platzhalter: Stelle dir {} wie kleine Krebszangen vor, die einen Wert an Ort und Stelle halten. Wenn du den Wert einer Variablen ausgibst, kann der Variablenname innerhalb der geschweiften Klammern stehen. Wenn du das Ergebnis der Auswertung eines Ausdrucks ausgeben willst, füge leere geschweifte Klammern in die Formatierungszeichenkette ein und gib dann nach der Formatierungszeichenkette eine durch Komma getrennte Liste von Ausdrücken ein, die in jedem leeren geschweiften Klammerplatzhalter in derselben Reihenfolge ausgegeben werden sollen. Das Ausgeben einer Variablen und des Ergebnisses eines Ausdrucks in einem Aufruf von println! würde wie folgt aussehen:

#![allow(unused)]
fn main() {
let x = 5;
let y = 10;

println!("x = {x} und y + 2 = {}", y + 2);
}

Dieser Code würde x = 5 und y + 2 = 12 ausgeben.

Testen des ersten Teils

Testen wir den ersten Teil des Ratespiels. Führe ihn mit cargo run aus:

$ cargo run
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished dev [unoptimized + debuginfo] target(s) in 6.44s
     Running `target/debug/guessing_game`
Rate die Zahl!
Bitte gib deine Schätzung ein.
6
Du hast geschätzt: 6

An diesem Punkt ist der erste Teil des Spiels abgeschlossen: Wir erhalten eine Eingabe über die Tastatur und geben sie dann aus.

Generieren einer Geheimzahl

Als Nächstes müssen wir eine Geheimzahl generieren, die der Benutzer versucht zu erraten. Die Geheimzahl sollte jedes Mal anders sein, damit das Spiel mehr als einmal Spaß macht. Wir werden eine Zufallszahl zwischen 1 und 100 verwenden, damit das Spiel nicht zu schwierig wird. Rust enthält noch keine Zufallszahl-Funktionalität in seiner Standardbibliothek. Das Rust-Team stellt jedoch eine Kiste rand mit besagter Funktionalität zur Verfügung.

Verwenden einer Kiste, um mehr Funktionalität zu erhalten

Denke daran, dass eine Kiste eine Sammlung von Rust-Quellcode-Dateien ist. Unser Projekt "Ratespiel" ist eine binäre Kiste (binary crate), die eine ausführbare Datei ist. Die Kiste rand ist eine Bibliotheks-Kiste (library crate), die Code enthält, der in anderen Programmen verwendet werden soll.

Das Koordinieren von externen Kisten ist der Bereich, in dem Cargo glänzt. Bevor wir Code schreiben können, der rand benutzt, müssen wir die Datei Cargo.toml so modifizieren, dass die Kiste rand als Abhängigkeit eingebunden wird. Öffne jetzt diese Datei und füge die folgende Zeile unten unter der Überschrift des Abschnitts [dependencies] hinzu, den Cargo für dich erstellt hat. Stelle sicher, dass du rand genau so angibst, wie wir es hier getan haben, andernfalls funktionieren die Codebeispiele in dieser Anleitung möglicherweise nicht.

Dateiname: Cargo.toml

[dependencies]
rand = "0.8.5"

In der Datei Cargo.toml ist alles, was nach einer Überschrift folgt, Teil dieses Abschnitts, der so lange andauert, bis ein anderer Abschnitt beginnt. Im Abschnitt [dependencies] teilst du Cargo mit, von welchen externen Kisten dein Projekt abhängt und welche Versionen dieser Kisten du benötigst. In diesem Fall spezifizieren wir die Kiste rand mit dem semantischen Versionsspezifikator 0.8.5. Cargo versteht semantische Versionierung (manchmal auch SemVer genannt), was ein Standard zum Schreiben von Versionsnummern ist. Die Angabe 0.8.5 ist eigentlich die Abkürzung für ^0.8.5, was für alle Versionen ab 0.8.5 und kleiner als 0.9.0 steht.

Cargo geht davon aus, dass die öffentliche API dieser Versionen kompatibel zur Version 0.8.5 ist und diese Angabe stellt sicher, dass du die neueste Patch-Version erhältst, die noch mit dem Code in diesem Kapitel kompiliert werden kann. Ab Version 0.9.0 ist nicht garantiert, dass die API mit der in den folgenden Beispielen verwendeten übereinstimmt.

Lass uns nun, ohne den Code zu ändern, das Projekt bauen, wie in Codeblock 2-2 gezeigt.

$ cargo build
    Updating crates.io index
  Downloaded rand v0.8.5
  Downloaded libc v0.2.127
  Downloaded getrandom v0.2.7
  Downloaded cfg-if v1.0.0
  Downloaded ppv-lite86 v0.2.16
  Downloaded rand_chacha v0.3.1
  Downloaded rand_core v0.6.3
   Compiling libc v0.2.127
   Compiling getrandom v0.2.7
   Compiling cfg-if v1.0.0
   Compiling ppv-lite86 v0.2.16
   Compiling rand_core v0.6.3
   Compiling rand_chacha v0.3.1
   Compiling rand v0.8.5
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished dev [unoptimized + debuginfo] target(s) in 2.53s

Codeblock 2-2: Die Ausgabe beim Ausführen von cargo build nach dem Hinzufügen der Kiste rand als Abhängigkeit

Möglicherweise siehst du unterschiedliche Versionsnummern (aber dank SemVer sind sie alle mit dem Code kompatibel!) und unterschiedliche Zeilen (je nach Betriebssystem), und die Zeilen können in einer anderen Reihenfolge erscheinen.

Wenn wir eine externe Abhängigkeit einfügen, holt Cargo die neuesten Versionen von allem was die Abhängigkeit aus der Registry benötigt, was eine Kopie der Daten von Crates.io ist. Crates.io ist der Ort, an dem die Menschen im Rust-Ökosystem ihre Open-Source-Rustprojekte für andere zur Nutzung bereitstellen.

Nach dem Aktualisieren der Registry überprüft Cargo den Abschnitt [dependencies] und lädt alle aufgelisteten Kisten herunter, die noch nicht heruntergeladen wurden. Obwohl wir nur rand als Abhängigkeit aufgelistet haben, hat sich Cargo in diesem Fall auch andere Kisten geschnappt, von denen rand abhängig ist, um zu funktionieren. Nachdem die Kisten heruntergeladen wurden, kompiliert Rust sie und kompiliert dann das Projekt mit den verfügbaren Abhängigkeiten.

Wenn du gleich wieder cargo build ausführst, ohne irgendwelche Änderungen vorzunehmen, erhältst du keine Ausgabe außer der Zeile Finished. Cargo weiß, dass es die Abhängigkeiten bereits heruntergeladen und kompiliert hat, und du hast in deiner Datei Cargo.toml nichts daran geändert. Cargo weiß auch, dass du nichts an deinem Code geändert hast, also wird dieser auch nicht neu kompiliert. Ohne etwas zu tun zu haben, wird es einfach beendet.

Wenn du die Datei src/main.rs öffnest, eine triviale Änderung vornimmst und sie dann speicherst und neu baust, siehst du nur zwei Zeilen Ausgabe:

$ cargo build
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished dev [unoptimized + debuginfo] target(s) in 2.53 secs

Diese Zeilen zeigen, dass Cargo nur den Build mit deiner winzigen Änderung an der Datei src/main.rs aktualisiert. Deine Abhängigkeiten haben sich nicht geändert, sodass Cargo weiß, dass es wiederverwenden kann, was es bereits heruntergeladen und kompiliert hat.

Sicherstellen reproduzierbarer Builds mit der Datei Cargo.lock

Cargo verfügt über einen Mechanismus, der sicherstellt, dass du jedes Mal, wenn du oder jemand anderes deinen Code baut, dasselbe Artefakt neu erstellen kannst: Cargo wird nur die Versionen der von dir angegebenen Abhängigkeiten verwenden, bis du etwas anderes angibst. Nehmen wir beispielsweise an, dass nächste Woche Version 0.8.6 der Kiste rand herauskommt und eine wichtige Fehlerkorrektur enthält, aber auch eine Regression, die deinen Code bricht. Um dies zu handhaben, erstellt Rust die Datei Cargo.lock beim ersten Mal, wenn du cargo build ausführst, die nun im guessing_game-Verzeichnis liegt.

Wenn du ein Projekt zum ersten Mal baust, ermittelt Cargo alle Versionen der Abhängigkeiten, die den Kriterien entsprechen, und schreibt sie dann in die Datei Cargo.lock. Wenn du dein Projekt in der Zukunft baust, wird Cargo sehen, dass die Datei Cargo.lock existiert und die dort angegebenen Versionen verwenden, anstatt die ganze Arbeit der Versionsfindung erneut zu machen. Auf diese Weise erhältst du automatisch einen reproduzierbaren Build. Mit anderen Worten, dein Projekt bleibt dank der Datei Cargo.lock auf 0.8.5, bis du explizit die Versionsnummer erhöhst. Da die Datei Cargo.lock für das reproduzierbare Bauen wichtig ist, wird sie oft zusammen mit dem restlichen Code deines Projekts in die Versionskontrolle eingecheckt.

Aktualisieren einer Kiste, um eine neue Version zu erhalten

Wenn du eine Kiste aktualisieren willst, bietet Cargo den Befehl update an, der die Datei Cargo.lock ignoriert und alle neuesten Versionen, die deinen Spezifikationen entsprechen, in Cargo.toml herausfindet. Cargo schreibt diese Versionen dann in die Datei Cargo.lock. Andernfalls wird Cargo standardmäßig nur nach Versionen größer als 0.8.5 und kleiner als 0.9.0 suchen. Wenn die Kiste rand zwei neue Versionen 0.8.6 und 0.9.0 veröffentlicht hat, würdest du folgendes sehen, wenn du cargo update ausführst:

$ cargo update
    Updating crates.io index
    Updating rand v0.8.5 -> v0.8.6

Cargo ignoriert die Version 0.9.0. An diesem Punkt würdest du auch eine Änderung in deiner Datei Cargo.lock bemerken, die feststellt, dass die Version der Kiste rand, die du jetzt benutzt, 0.8.6 ist. Um die rand-Version 0.9.0 oder irgendeine Version aus der 0.9.x-Serie zu verwenden, müsstest du stattdessen die Datei Cargo.toml anpassen, damit sie wie folgt aussieht:

[dependencies]
rand = "0.9.0"

Wenn du das nächste Mal cargo build ausführst, wird Cargo die Registry der verfügbaren Kisten aktualisieren und deine rand-Anforderungen entsprechend der von dir angegebenen neuen Version neu bewerten.

Es gibt noch viel mehr über Cargo und seinem Ökosystem zu sagen, das wir in Kapitel 14 besprechen werden, aber für den Moment ist das alles, was du wissen musst. Cargo macht es sehr einfach, Bibliotheken wiederzuverwenden, sodass die Rust-Entwickler in der Lage sind, kleinere Projekte zu schreiben, die aus einer Reihe von Paketen zusammengestellt werden.

Generieren einer Zufallszahl

Beginnen wir mit rand, um eine Zahl zum Raten zu erzeugen. Der nächste Schritt ist src/main.rs zu ändern, wie in Codeblock 2-3 gezeigt.

Dateiname: src/main.rs

use std::io;
use rand::Rng;

fn main() {
    println!("Rate die Zahl!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("Die Geheimzahl ist: {secret_number}");

    println!("Bitte gib deine Schätzung ein.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Fehler beim Lesen der Zeile");

    println!("Du hast geschätzt: {guess}");
}

Codeblock 2-3: Hinzufügen von Code zum Generieren einer Zufallszahl

Zuerst fügen wir die Zeile use rand::Rng; hinzu. Das Merkmal (trait) Rng definiert Methoden, die Zufallszahlengeneratoren implementieren, und dieses Merkmal muss im Gültigkeitsbereich sein, damit wir diese Methoden verwenden können. In Kapitel 10 werden Merkmale im Detail behandelt.

Als nächstes fügen wir zwei Zeilen in der Mitte hinzu. In der ersten Zeile rufen wir die Funktion rand::thread_rng auf, die uns den speziellen Zufallszahlengenerator zurückgibt, den wir verwenden werden: Einen, der lokal zum aktuellen Ausführungsstrang (thread) ist und vom Betriebssystem initialisiert (seeded) wird. Dann rufen wir die Methode gen_range des Zufallszahlengenerators auf. Diese Methode wird durch das Merkmal Rng definiert, das wir mit der Anweisung use rand::Rng; in den Gültigkeitsbereich gebracht haben. Die Methode gen_range nimmt einen Bereichsausdruck als Argument und generiert eine Zufallszahl in diesem Bereich. Ein Bereichsausdruck hat die Form start..=end und er beinhaltet die Untergrenze und die Obergrenze, sodass wir 1..=100 angeben müssen, um eine Zahl zwischen 1 und 100 zu erhalten.

Hinweis: Du wirst nicht immer wissen, welche Merkmale du verwenden sollst und welche Methoden und Funktionen einer Kiste du aufrufen musst, daher hat jede Kiste eine Dokumentation mit einer Anleitungen zur Verwendung der Kiste. Eine weitere nette Funktionalität von Cargo ist, dass das Ausführen des Kommandos cargo doc --open die von all deinen Abhängigkeiten bereitgestellte Dokumentation lokal zusammenstellt und in deinem Browser öffnet. Wenn du an anderen Funktionen der Kiste rand interessiert bist, führe zum Beispiel cargo doc --open aus und klicke auf rand in der Seitenleiste links.

Die zweite neue Zeile gibt die Geheimzahl aus. Das ist hilfreich während wir das Programm entwickeln, um es testen zu können, aber wir werden es aus der finalen Version entfernen. Es ist kein echtes Spiel, wenn das Programm die Antwort ausgibt, sobald es startet!

Versuche, das Programm einige Male auszuführen:

$ cargo run
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished dev [unoptimized + debuginfo] target(s) in 2.53s
     Running `target/debug/guessing_game`
Rate die Zahl!
Die Geheimzahl ist: 7
Bitte gib deine Schätzung ein.
4
Du hast geschätzt: 4

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/guessing_game`
Rate die Zahl!
Die Geheimzahl ist: 83
Bitte gib deine Schätzung ein.
5
Du hast geschätzt: 5

Du solltest verschiedene Zufallszahlen erhalten und sie sollten alle zwischen 1 und 100 sein. Großartige Arbeit!

Vergleichen der Schätzung mit der Geheimzahl

Jetzt, da wir eine Benutzereingabe und eine Zufallszahl haben, können wir sie vergleichen. Dieser Schritt ist in Codeblock 2-4 dargestellt. Beachte, dass sich dieser Code noch nicht ganz kompilieren lässt, wie wir erklären werden.

Dateiname: src/main.rs

use rand::Rng;
use std::cmp::Ordering;
use std::io;

fn main() {
    // --abschneiden--
    println!("Rate die Zahl!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("Die Geheimzahl ist: {secret_number}");

    println!("Bitte gib deine Schätzung ein.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Fehler beim Lesen der Zeile");

    println!("Du hast geschätzt: {guess}");

    match guess.cmp(&secret_number) {
        Ordering::Less => println!("Zu klein!"),
        Ordering::Greater => println!("Zu groß!"),
        Ordering::Equal => println!("Du hast gewonnen!"),
    }
}

Codeblock 2-4: Behandeln der möglichen Rückgabewerte beim Vergleich zweier Zahlen

Zuerst fügen wir eine weitere use-Anweisung hinzu, die einen Typ namens std::cmp::Ordering aus der Standardbibliothek in den Gültigkeitsbereich bringt. Der Typ Ordering ist eine weitere Aufzählung und hat die Varianten Less, Greater und Equal. Dies sind die drei Ergebnisse, die möglich sind, wenn man zwei Werte vergleicht.

Dann fügen wir unten fünf neue Zeilen hinzu, die den Typ Ordering verwenden. Die cmp-Methode vergleicht zwei Werte und kann auf alles, was verglichen werden kann, angewendet werden. Sie braucht eine Referenz auf das, was du vergleichen willst: Hier wird guess mit secret_number verglichen. Dann gibt sie eine Variante der Ordering-Aufzählung zurück, die wir mit der use-Anweisung in den Gültigkeitsbereich gebracht haben. Wir verwenden einen match-Ausdruck, um zu entscheiden, was als nächstes zu tun ist, basierend darauf, welche Ordering-Variante vom Aufruf von cmp mit den Werten in guess und secret_number zurückgegeben wurde.

Ein match-Ausdruck besteht aus Zweigen (arms). Ein Zweig besteht aus einem Muster (pattern) und dem Code, der ausgeführt werden soll, wenn der Wert, der am Anfang des match-Ausdrucks steht, zum Muster dieses Zweigs passt. Rust nimmt den Wert, der bei match angegeben wurde, und schaut nacheinander durch das Muster jedes Zweigs. Das match-Konstrukt und die Muster sind mächtige Funktionalitäten in Rust, mit denen du eine Vielzahl von Situationen ausdrücken kannst, auf die dein Code stoßen könnte, und die sicherstellen, dass du sie alle behandelst. Diese Funktionalitäten werden ausführlich in Kapitel 6 bzw. Kapitel 18 behandelt.

Gehen wir ein Beispiel dafür durch, was mit dem hier verwendeten match-Ausdruck geschehen würde. Angenommen, der Benutzer hat 50 geschätzt und die zufällig generierte Geheimzahl ist diesmal 38.

Wenn der Code 50 mit 38 vergleicht, gibt die cmp-Methode Ordering::Greater zurück, weil 50 größer als 38 ist. Der match-Ausdruck erhält den Wert Ordering::Greater und beginnt mit der Überprüfung des Musters jedes Zweigs. Er schaut auf das Muster Ordering::Less des ersten Zweigs und sieht, dass der Wert Ordering::Greater nicht mit Ordering::Less übereinstimmt, also ignoriert er den Code in diesem Zweig und geht zum nächsten Zweig über. Das Muster Ordering::Greater des nächsten Zweigs passt zu Ordering::Greater! Der dazugehörige Code in diesem Zweig wird ausgeführt und Zu groß! auf den Bildschirm ausgegeben. Der match-Ausdruck endet nach der ersten erfolgreichen Übereinstimmung, sodass der letzte Zweig in diesem Szenario nicht berücksichtigt wird.

Der Code in Codeblock 2-4 lässt sich jedoch noch nicht kompilieren. Lass es uns versuchen:

$ cargo build
   Compiling libc v0.2.86
   Compiling getrandom v0.2.2
   Compiling cfg-if v1.0.0
   Compiling ppv-lite86 v0.2.10
   Compiling rand_core v0.6.2
   Compiling rand_chacha v0.3.0
   Compiling rand v0.8.5
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
error[E0308]: mismatched types
  --> src/main.rs:22:21
   |
22 |     match guess.cmp(&secret_number) {
   |                 --- ^^^^^^^^^^^^^^ expected `&String`, found `&{integer}`
   |                 |
   |                 arguments to this method are incorrect
   |
   = note: expected reference `&String`
              found reference `&{integer}`
note: method defined here
  --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/cmp.rs:814:8

For more information about this error, try `rustc --explain E0308`.
error: could not compile `guessing_game` (bin "guessing_game") due to 1 previous error

Die Kernbotschaft des Fehlers besagt, dass es nicht übereinstimmende Typen (mismatched types) gibt. Rust hat ein starkes, statisches Typsystem. Es hat jedoch auch eine Typ-Inferenz. Als wir let mut guess = String::new() schrieben, konnte Rust daraus schließen, dass guess ein String sein sollte, und zwang uns nicht, den Typ anzugeben. Die secret_number hingegen ist ein Zahlentyp. Einige Zahlentypen können einen Wert zwischen 1 und 100 haben: i32, eine 32-Bit-Zahl; u32, eine 32-Bit-Zahl ohne Vorzeichen; i64, eine 64-Bit-Zahl; sowie andere. Solange nicht anders angegeben, verwendet Rust standardmäßig i32, was der Typ von secret_number ist, es sei denn, du fügst an anderer Stelle Typinformationen hinzu, die Rust veranlassen würden, auf einen anderen numerischen Typ zu schließen. Der Grund für den Fehler liegt darin, dass Rust eine Zeichenkette und einen Zahlentyp nicht vergleichen kann.

Letztendlich wollen wir den String, den das Programm als Eingabe liest, in einen echten Zahlentyp umwandeln, damit wir ihn numerisch mit der Geheimzahl vergleichen können. Das tun wir, indem wir folgendes zum main-Funktionsrumpf hinzufügen:

Dateiname: src/main.rs

use rand::Rng;
use std::cmp::Ordering;
use std::io;

fn main() {
    println!("Rate die Zahl!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("Die Geheimzahl ist: {secret_number}");

    println!("Bitte gib deine Schätzung ein.");

    // --abschneiden--

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Fehler beim Lesen der Zeile");

    let guess: u32 = guess.trim().parse().expect("Bitte gib eine Zahl ein!");

    println!("Du hast geschätzt: {guess}");

    match guess.cmp(&secret_number) {
        Ordering::Less => println!("Zu klein!"),
        Ordering::Greater => println!("Zu groß!"),
        Ordering::Equal => println!("Du hast gewonnen!"),
    }
}

Die Zeile lautet:

let guess: u32 = guess.trim().parse().expect("Bitte gib eine Zahl ein!");

Wir erstellen eine Variable mit dem Namen guess. Aber warte, hat das Programm nicht bereits eine Variable namens guess? Ja, aber Rust erlaubt uns, den vorherigen Wert von guess mit einem neuen Wert zu verschatten (shadow). Durch das Verschatten können wir den Variablennamen guess wiederverwenden, anstatt uns zu zwingen, zwei eindeutige Variablen zu erstellen, z.B. guess_str und guess. Wir werden dies in Kapitel 3 ausführlicher behandeln, aber für den Moment solltst du wissen, dass diese Funktionalität oft verwendet wird, wenn du einen Wert von einem Typ in einen anderen Typ konvertieren willst.

Wir binden guess an den Ausdruck guess.trim().parse(). Das guess im Ausdruck bezieht sich auf das ursprüngliche guess, das ein String mit der Eingabe darin war. Die trim-Methode der String-Instanz wird alle Leerzeichen am Anfang und am Ende entfernen. Obwohl u32 nur numerische Zeichen enthalten kann, muss der Benutzer die Eingabetaste drücken, um read_line zufriedenzustellen. Wenn der Benutzer die Eingabetaste drückt, wird der Zeichenkette ein Zeilenumbruchszeichen (newline character) hinzugefügt. Wenn der Benutzer z.B. 5 eingibt und die Eingabetaste drückt, sieht guess wie folgt aus: 5\n. Das \n steht für „Zeilenumbruch“ (newline), das Ergebnis des Drückens der Eingabetaste. (Unter Windows ergibt das Drücken der Eingabetaste einen Wagenrücklauf (carriage return) und einen Zeilenumbruch (newline): \r\n) Die trim-Methode entfernt \n und \r\n, was nur 5 ergibt.

Die parse-Methode für Zeichenketten konvertiert eine Zeichenkette in einen anderen Typ. Hier verwenden wir sie, um eine Zeichenkette in eine Zahl umzuwandeln. Wir müssen Rust den genauen Zahlentyp mitteilen, den wir wollen, indem wir let guess: u32 verwenden. Der Doppelpunkt (:) nach guess sagt Rust, dass wir den Typ der Variablen annotieren werden. Rust hat ein paar eingebaute Zahlentypen; u32, das du hier siehst, ist eine vorzeichenlose 32-Bit-Ganzzahl. Es ist eine gute Standardwahl für eine kleine positive Zahl. Über andere Zahlentypen erfährst du in Kapitel 3.

Zusätzlich bedeuten die Annotation u32 in diesem Beispielprogramm und der Vergleich mit secret_number, dass Rust daraus ableiten wird, dass secret_number ebenfalls ein u32 sein sollte. Nun wird also der Vergleich zwischen zwei Werten desselben Typs durchgeführt!

Die Methode parse funktioniert nur bei Zeichen, die logisch in Zahlen umgewandelt werden können und kann daher leicht Fehler verursachen. Wenn die Zeichenkette zum Beispiel A👍% enthielte, gäbe es keine Möglichkeit, dies in eine Zahl umzuwandeln. Da dies fehlschlagen könnte, gibt die parse-Methode einen Result-Typ zurück, ähnlich wie die read_line-Methode (weiter oben in „Behandeln potentieller Fehler mit Result“). Wir werden dieses Result auf die gleiche Weise behandeln, indem wir erneut expect verwenden. Wenn parse eine Err-Variante von Result zurückgibt, weil es keine Zahl aus der Zeichenkette erzeugen konnte, wird der expect-Aufruf das Spiel zum Absturz bringen und die Nachricht ausgeben, die wir ihm geben. Wenn parse die Zeichenkette erfolgreich in eine Zahl umwandeln kann, gibt es die Ok-Variante von Result zurück, und expect gibt die Zahl zurück, die wir vom Ok-Wert erwarten.

Lassen wir das Programm jetzt laufen:

$ cargo run
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished dev [unoptimized + debuginfo] target(s) in 0.43s
     Running `target/debug/guessing_game`
Rate die Zahl!
Die Geheimzahl ist: 58
Bitte gib deine Schätzung ein.
  76
Du hast geschätzt: 76
Zu groß!

Schön! Auch wenn vor der Schätzung Leerzeichen eingegeben wurden, fand das Programm dennoch heraus, dass der Benutzer 76 geschätzt hat. Führe das Programm einige Male aus, um das unterschiedliche Verhalten bei verschiedenen Eingabearten zu überprüfen: Schätze die Zahl richtig, schätze eine zu große Zahl und schätze eine zu kleine Zahl.

Der Großteil des Spiels funktioniert jetzt, aber der Benutzer kann nur eine Schätzung anstellen. Ändern wir das, indem wir eine Schleife hinzufügen!

Zulassen mehrerer Schätzungen mittels Schleife

Das Schlüsselwort loop erzeugt eine Endlosschleife. Wir fügen jetzt eine Schleife hinzu, um den Benutzern mehr Chancen zu geben, die Zahl zu erraten:

Dateiname: src/main.rs

use rand::Rng;
use std::cmp::Ordering;
use std::io;

fn main() {
    println!("Rate die Zahl!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    // --abschneiden--

    println!("Die Geheimzahl ist: {secret_number}");

    loop {
        println!("Bitte gib deine Schätzung ein.");

        // --abschneiden--

        let mut guess = String::new();

        io::stdin()
            .read_line(&mut guess)
            .expect("Fehler beim Lesen der Zeile");

        let guess: u32 = guess.trim().parse().expect("Bitte gib eine Zahl ein!");

        println!("Du hast geschätzt: {guess}");

        match guess.cmp(&secret_number) {
            Ordering::Less => println!("Zu klein!"),
            Ordering::Greater => println!("Zu groß!"),
            Ordering::Equal => println!("Du hast gewonnen!"),
        }
    }
}

Wie du sehen kannst, haben wir alles ab der Eingabeaufforderung für die Schätzung in eine Schleife verschoben. Achte darauf, die Zeilen innerhalb der Schleife jeweils um weitere vier Leerzeichen einzurücken und das Programm erneut auszuführen. Beachte, dass es ein neues Problem gibt, weil das Programm genau das tut, was wir ihm gesagt haben: Frage für immer nach einer weiteren Schätzung! Es sieht nicht so aus, als könne der Benutzer das Programm beenden!

Der Benutzer könnte das Programm jederzeit mit dem Tastaturkürzel Strg+c unterbrechen. Aber es gibt noch eine andere Möglichkeit, diesem unersättlichen Monster zu entkommen, wie in der parse-Diskussion in „Vergleichen der Schätzung mit der Geheimzahl“ erwähnt: Wenn der Benutzer eine Antwort ohne Zahl eingibt, stürzt das Programm ab. Wir können das ausnutzen, um dem Benutzer zu erlauben das Programm zu beenden, wie hier gezeigt:

$ cargo run
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished dev [unoptimized + debuginfo] target(s) in 1.50s
     Running `target/debug/guessing_game`
Rate die Zahl!
Die Geheimzahl ist: 59
Bitte gib deine Schätzung ein.
45
Du hast geschätzt: 45
Zu klein!
Bitte gib deine Schätzung ein.
60
Du hast geschätzt: 60
Zu groß!
Bitte gib deine Schätzung ein.
59
Du hast geschätzt: 59
Du hast gewonnen!
Bitte gib deine Schätzung ein.
quit
thread 'main' panicked at 'Bitte gib eine Zahl ein!: ParseIntError { kind: InvalidDigit }', src/libcore/result.rs:999:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Mit der Eingabe von quit wird das Spiel beendet, aber das gilt auch für alle anderen Eingaben, die keine Zahlen sind. Dies ist jedoch, gelinde gesagt, suboptimal. Wir wollen, dass das Spiel automatisch beendet wird, wenn die richtige Zahl erraten wird.

Beenden nach einer korrekten Schätzung

Programmieren wir das Spiel so, dass es beendet wird, wenn der Benutzer gewinnt, indem wir eine break-Anweisung hinzufügen:

Dateiname: src/main.rs

use rand::Rng;
use std::cmp::Ordering;
use std::io;

fn main() {
    println!("Rate die Zahl!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("Die Geheimzahl ist: {secret_number}");

    loop {
        println!("Bitte gib deine Schätzung ein.");

        let mut guess = String::new();

        io::stdin()
            .read_line(&mut guess)
            .expect("Fehler beim Lesen der Zeile");

        let guess: u32 = guess.trim().parse().expect("Bitte gib eine Zahl ein!");

        println!("Du hast geschätzt: {guess}");

        // --abschneiden--

        match guess.cmp(&secret_number) {
            Ordering::Less => println!("Zu klein!"),
            Ordering::Greater => println!("Zu groß!"),
            Ordering::Equal => {
                println!("Du hast gewonnen!");
                break;
            }
        }
    }
}

Das Hinzufügen der break-Zeile nach Du hast gewonnen! bewirkt, dass das Programm die Schleife verlässt, wenn der Benutzer die Geheimzahl richtig errät. Die Schleife zu verlassen bedeutet auch, das Programm zu beenden, da die Schleife der letzte Teil von main ist.

Behandeln ungültiger Eingaben

Um das Verhalten des Spiels weiter zu verfeinern, sollten wir das Programm nicht abstürzen lassen, wenn der Benutzer keine gültige Zahl eingibt, sondern dafür sorgen, dass das Spiel ungültige Zahlen ignoriert, damit der Benutzer weiter raten kann. Das können wir erreichen, indem wir die Zeile ändern, in der guess von String in u32 umgewandelt wird, wie in Codeblock 2-5 gezeigt.

Dateiname: src/main.rs

use rand::Rng;
use std::cmp::Ordering;
use std::io;

fn main() {
    println!("Rate die Zahl!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("Die Geheimzahl ist: {secret_number}");

    loop {
        println!("Bitte gib deine Schätzung ein.");

        let mut guess = String::new();

        // --abschneiden--

        io::stdin()
            .read_line(&mut guess)
            .expect("Fehler beim Lesen der Zeile");

        let guess: u32 = match guess.trim().parse() {
            Ok(num) => num,
            Err(_) => continue,
        };

        println!("Du hast geschätzt: {guess}");

        // --abschneiden--

        match guess.cmp(&secret_number) {
            Ordering::Less => println!("Zu klein!"),
            Ordering::Greater => println!("Zu groß!"),
            Ordering::Equal => {
                println!("Du hast gewonnen!");
                break;
            }
        }
    }
}

Codeblock 2-5: Ignorieren einer ungültigen Zahl und Auffordern zu einer weiteren Schätzung, anstatt das Programm zum Absturz zu bringen

Das Umstellen von einem expect-Aufruf zu einem match-Ausdruck ist eine Möglichkeit für den Übergang vom Absturz bei einem Fehler zur Behandlung des Fehlers. Denke daran, dass parse einen Result-Typ zurückgibt und Result eine Aufzählung ist, die die Varianten Ok und Err hat. Wir benutzen hier einen match-Ausdruck, wie wir es mit dem Ordering-Ergebnis der cmp-Methode getan haben.

Wenn parse in der Lage ist, die Zeichenkette erfolgreich in eine Zahl umzuwandeln, gibt es einen Ok-Wert zurück, der die resultierende Zahl enthält. Dieser Ok-Wert wird mit dem Muster des ersten Zweigs übereinstimmen und der match-Ausdruck wird nur den num-Wert zurückgeben, der durch parse erzeugt und in den Ok-Wert eingefügt wurde. Diese Zahl wird in der neuen guess-Variable, die wir erzeugen, genau dort landen, wo wir sie haben wollen.

Wenn parse nicht in der Lage ist, die Zeichenkette in eine Zahl umzuwandeln, gibt es einen Err-Wert zurück, der mehr Informationen über den Fehler enthält. Der Err-Wert stimmt nicht mit dem Ok(num)-Muster im ersten match-Zweig überein, aber er stimmt mit dem Err(_)-Muster im zweiten Zweig überein. Der Unterstrich _ ist ein Auffangwert; in diesem Beispiel sagen wir, dass alle Err-Werte übereinstimmen sollen, egal welche Informationen sie enthalten. Das Programm wird also den Code continue des zweiten Zweigs ausführen, der das Programm anweist, zur nächsten loop-Iteration zu gehen und nach einer weiteren Schätzung zu fragen. Effektiv ignoriert das Programm also alle Fehler, die bei parse auftreten könnten!

Jetzt sollte alles im Programm wie erwartet funktionieren. Lass es uns versuchen:

$ cargo run
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
     Running `target/debug/guessing_game`
Rate die Zahl!
Die Geheimzahl ist: 61
Bitte gib deine Schätzung ein.
10
Du hast geschätzt: 10
Zu klein!
Bitte gib deine Schätzung ein.
99
Du hast geschätzt: 99
Zu groß!
Bitte gib deine Schätzung ein.
foo
Bitte gib deine Schätzung ein.
61
Du hast geschätzt: 61
Du hast gewonnen!

Fantastisch! Mit einem winzigen letzten Feinschliff beenden wir das Ratespiel. Denke daran, dass das Programm immer noch die Geheimzahl ausgibt. Das hat beim Testen gut funktioniert, aber es ruiniert das Spiel. Löschen wir das println!, das die Geheimzahl ausgibt. Codeblock 2-6 zeigt den finalen Code.

Dateiname: src/main.rs

use rand::Rng;
use std::cmp::Ordering;
use std::io;

fn main() {
    println!("Rate die Zahl!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    loop {
        println!("Bitte gib deine Schätzung ein.");

        let mut guess = String::new();

        io::stdin()
            .read_line(&mut guess)
            .expect("Fehler beim Lesen der Zeile");

        let guess: u32 = match guess.trim().parse() {
            Ok(num) => num,
            Err(_) => continue,
        };

        println!("Du hast geschätzt: {guess}");

        match guess.cmp(&secret_number) {
            Ordering::Less => println!("Zu klein!"),
            Ordering::Greater => println!("Zu groß!"),
            Ordering::Equal => {
                println!("Du hast gewonnen!");
                break;
            }
        }
    }
}

Codeblock 2-6: Vollständiger Code des Ratespiels

An diesem Punkt hast du das Ratespiel erfolgreich aufgebaut. Herzlichen Glückwunsch!

Zusammenfassung

Dieses Projekt war eine praktische Möglichkeit, dich mit vielen neuen Rust-Konzepten vertraut zu machen: let, match, Funktionen, das Verwenden von externen Kisten und mehr. In den nächsten Kapiteln erfährst du mehr über diese Konzepte. Kapitel 3 behandelt Konzepte, über die die meisten Programmiersprachen verfügen, z.B. Variablen, Datentypen und Funktionen, und zeigt, wie man sie in Rust verwendet. Kapitel 4 untersucht die Eigentümerschaft, eine Funktionalität, die Rust von anderen Sprachen unterscheidet. In Kapitel 5 werden Strukturen (structs) und die Methodensyntax besprochen und in Kapitel 6 wird die Funktionsweise von Aufzählungen erläutert.

Allgemeine Programmierkonzepte

Dieses Kapitel behandelt Konzepte, die in fast jeder Programmiersprache vorkommen, und wie sie in Rust funktionieren. Viele Programmiersprachen haben in ihrem Kern viel gemeinsam. Keines der in diesem Kapitel vorgestellten Konzepte ist einzigartig für Rust, aber wir werden sie im Kontext von Rust besprechen und die Konventionen beim Verwenden dieser Konzepte erklären.

Insbesondere lernst du etwas über Variablen, Basistypen (basic types), Funktionen, Kommentare und Kontrollfluss (control flow). Diese Grundlagen werden in jedem Rust-Programm vorhanden sein, und wenn du sie früh lernst, erhältst du eine starke Basis, auf der du aufbauen kannst.

Schlüsselwörter

Die Sprache Rust hat eine Reihe von Schlüsselwörtern (keywords), die wie in anderen Sprachen nur der Sprache selbst vorbehalten sind. Denke daran, dass du diese Wörter nicht als Namen von Variablen oder Funktionen verwenden kannst. Die meisten der Schlüsselwörter haben spezielle Bedeutungen und du wirst sie für verschiedene Aufgaben in deinen Rust-Programmen verwenden; einige wenige haben aktuell noch keine Funktionalität, die mit ihnen verbunden ist, sondern wurden für Funktionalität reserviert, die in Zukunft zu Rust hinzugefügt werden könnte. Eine Liste der Schlüsselwörter findest du in Anhang A.

Variablen und Veränderbarkeit

Wie im Abschnitt „Speichern von Werten mit Variablen“ erwähnt, sind Variablen standardmäßig unveränderbar. Dies ist einer der vielen Stupser, die Rust dir gibt, um deinen Code so zu schreiben, dass du die Vorteile von Sicherheit (safety) und einfacher Nebenläufigkeit (easy concurrency) nutzt, die Rust bietet. Du hast jedoch immer noch die Möglichkeit, deine Variablen veränderbar (mutable) zu machen. Lass uns untersuchen, wie und warum Rust dich dazu ermutigt, die Unveränderbarkeit (immutability) zu bevorzugen, und warum du manchmal vielleicht davon abweichen möchtest.

Wenn eine Variable unveränderbar ist, kannst du deren Wert nicht mehr ändern, sobald ein Wert gebunden ist. Um dies zu veranschaulichen, lege ein neues Projekt namens variables in deinem projects-Verzeichnis an, indem du cargo new variables aufrufst.

Öffne dann in deinem neuen Verzeichnis variables die Datei src/main.rs und ersetze dessen Code durch folgenden Code, der sich sich noch nicht kompilieren lässt:

Dateiname: src/main.rs

fn main() {
    let x = 5;
    println!("Der Wert von x ist: {x}");
    x = 6;
    println!("Der Wert von x ist: {x}");
}

Speichere und starte das Programm mit cargo run. Du solltest eine Fehlermeldung über einen Unveränderbarkeitsfehler erhalten, wie in dieser Ausgabe gezeigt:

$ cargo run
   Compiling variables v0.1.0 (file:///projects/variables)
error[E0384]: cannot assign twice to immutable variable `x`
 --> src/main.rs:4:5
  |
2 |     let x = 5;
  |         -
  |         |
  |         first assignment to `x`
  |         help: consider making this binding mutable: `mut x`
3 |     println!("Der Wert von x ist: {}", x);
4 |     x = 6;
  |     ^^^^^ cannot assign twice to immutable variable

For more information about this error, try `rustc --explain E0384`.
error: could not compile `variables` (bin "variables") due to 1 previous error

Dieses Beispiel zeigt, wie der Compiler dir hilft, Fehler in deinen Programmen zu finden. Kompilierfehler können frustrierend sein, aber eigentlich bedeuten sie nur, dass dein Programm noch nicht sicher das tut, was du willst; sie bedeuten nicht, dass du kein guter Programmierer bist! Erfahrene Rust-Entwickler bekommen ebenfalls noch Kompilierfehler.

Du hast die Fehlermeldung cannot assign twice to immutable variable x erhalten, weil du versucht hast, der unveränderbaren Variablen x einen zweiten Wert zuzuweisen.

Es ist wichtig, dass wir Kompilierzeitfehler erhalten, wenn wir versuchen, einen Wert zu ändern, der als unveränderbar gekennzeichnet ist, denn genau diese Situation kann zu Fehlern führen. Wenn ein Teil unseres Codes von der Annahme ausgeht, dass sich ein Wert niemals ändern wird, und ein anderer Teil unseres Codes diesen Wert ändert, ist es möglich, dass der erste Teil des Codes nicht das tut, wozu er entwickelt wurde. Die Ursache für diese Art von Fehler kann im Nachhinein schwer aufzuspüren sein, besonders wenn das zweite Stück Code den Wert nur gelegentlich ändert. In Rust garantiert der Compiler, dass sich ein Wert tatsächlich nicht ändert, wenn du angibst, dass er sich nicht ändern darf, du musst also nicht selbst darauf achten. Dein Code ist somit leichter zu durchschauen.

Veränderbarkeit kann jedoch sehr nützlich sein und das Erstellen von Code erleichtern. Obwohl Variablen standardmäßig unveränderbar sind, kannst du sie veränderbar machen, indem du vor den Variablennamen mut angibst, wie du es in Kapitel 2 getan hast. Das Hinzufügen von mut vermittelt den zukünftigen Lesern des Codes die Absicht, dass andere Teile des Codes den Wert dieser Variablen ändern werden.

Lass uns zum Beispiel src/main.rs wie folgt ändern:

Dateiname: src/main.rs

fn main() {
    let mut x = 5;
    println!("Der Wert von x ist: {x}");
    x = 6;
    println!("Der Wert von x ist: {x}");
}

Wenn wir das Programm jetzt ausführen, bekommen wir dies:

$ cargo run
   Compiling variables v0.1.0 (file:///projects/variables)
    Finished dev [unoptimized + debuginfo] target(s) in 0.30s
     Running `target/debug/variables`
Der Wert von x ist: 5
Der Wert von x ist: 6

Wir dürfen den Wert, an den sich x bindet, von 5 auf 6 ändern, wenn mut verwendet wird. Letztendlich ist es deine Entscheidung, ob du Veränderbarkeit einsetzen willst oder nicht, und es hängt davon ab, was du in der jeweiligen Situation für am sinnvollsten hältst.

Konstanten

Wie unveränderbare Variablen sind Konstanten Werte, die an einen Namen gebunden sind und sich nicht ändern dürfen, aber es gibt einige Unterschiede zwischen Konstanten und Variablen.

Erstens ist es dir nicht erlaubt, mut mit Konstanten zu verwenden. Konstanten sind nicht nur von vornherein unveränderbar – sie sind immer unveränderbar. Du deklarierst Konstanten mit dem Schlüsselwort const anstelle des Schlüsselworts let und der Typ des Wertes muss annotiert werden. Wir sind dabei, Typen und Typ-Annotationen im nächsten Abschnitt „Datentypen“ zu behandeln, also mach dir jetzt keine Gedanken über die Details. Du musst nur wissen, dass du den Typ immer annotieren musst.

Konstanten können in jedem Gültigkeitsbereich deklariert werden, auch im globalen Gültigkeitsbereich, was sie für Werte nützlich macht, über die viele Teile des Codes Bescheid wissen müssen.

Der letzte Unterschied besteht darin, dass Konstanten nur auf einen konstanten Ausdruck gesetzt werden dürfen, nicht auf einen Wert, der nur zur Laufzeit berechnet werden könnte.

Hier ist ein Beispiel für eine Konstantendeklaration:

#![allow(unused)]
fn main() {
const THREE_HOURS_IN_SECONDS: u32 = 60 * 60 * 3;
}

Der Name der Konstante lautet THREE_HOURS_IN_SECONDS und ihr Wert wird auf das Ergebnis der Multiplikation von 60 (die Anzahl der Sekunden in einer Minute) mal 60 (die Anzahl der Minuten in einer Stunde) mal 3 (die Anzahl der Stunden, die wir in diesem Programm zählen wollen). Die Namenskonvention von Rust für Konstanten ist die Verwendung von Großbuchstaben mit Unterstrichen zwischen den Wörtern. Der Compiler ist in der Lage, eine begrenzte Anzahl von Operationen zur Kompilierzeit auszuwerten, was uns die Möglichkeit gibt, diesen Wert so zu schreiben, dass er leichter zu verstehen und zu überprüfen ist, als wenn diese Konstante auf den Wert 10.800 gesetzt wäre. Siehe die Rust-Referenz, Abschnitt über die Auswertung von Konstanten für weitere Informationen darüber, welche Operationen bei der Deklaration von Konstanten verwendet werden können.

Konstanten sind für die gesamte Laufzeit eines Programms in dem Gültigkeitsbereich gültig, in dem sie deklariert wurden. Damit sind sie eine nützliche Wahl für Werte in deiner Anwendungsdomäne, über die mehrere Teile des Programms Bescheid wissen müssen, z.B. die maximale Punktzahl, die jeder Spieler eines Spiels erhalten darf, oder die Lichtgeschwindigkeit.

Das Benennen von hartkodierten Werten, die im gesamten Programm als Konstanten verwendet werden, ist nützlich, um die Bedeutung dieses Wertes zukünftigen Code-Betreuern zu vermitteln. Es ist auch hilfreich, nur eine Stelle in deinem Code zu haben, die du ändern musst, wenn der hartkodierte Wert in Zukunft aktualisiert werden müsste.

Verschatten (shadowing)

Wie du in der Anleitung zum Ratespiel in Kapitel 2 gesehen hast, kannst du eine neue Variable mit dem gleichen Namen wie eine vorherige Variable deklarieren. Die Rust-Entwickler sagen, dass die erste Variable von der zweiten verschattet (shadowed) wird, was bedeutet, dass die zweite Variable das ist, was der Compiler sieht, wenn du den Namen der Variable verwendest. Die zweite Variable verschattet die erste und nimmt alle Verwendungen des Variablennamens auf sich, bis sie entweder selbst verschattet wird oder der Gültigkeitsbereich endet. Wir können eine Variable verschatten, indem wir denselben Variablenamen verwenden und das Schlüsselwort let wie folgt wiederholen:

Dateiname: src/main.rs

fn main() {
    let x = 5;

    let x = x + 1;

    {
        let x = x * 2;
        println!("Der Wert von x im inneren Gültigkeitsbereich ist: {x}");
    }

    println!("Der Wert von x ist: {x}");
}

Dieses Programm bindet zunächst x an den Wert 5. Dann wird eine neue Variable x erzeugt, indem let x = wiederholt wird, wobei der ursprüngliche Wert genommen und 1 hinzugefügt wird, sodass der Wert von x dann 6 ist. Innerhalb eines inneren Gültigkeitsbereichs, der durch die geschweiften Klammern geschaffen wird, verschattet die dritte let-Anweisung dann ebenfalls x und erzeugt eine neue Variable, wobei der vorherige Wert mit 2 multipliziert wird, um x einen Wert von 12 zu geben. Wenn dieser Gültigkeitsbereich zu Ende ist, endet die innere Verschattung und x wird wieder zu 6. Wenn wir dieses Programm ausführen, wird es folgendes ausgeben:

$ cargo run
   Compiling variables v0.1.0 (file:///projects/variables)
    Finished dev [unoptimized + debuginfo] target(s) in 0.31s
     Running `target/debug/variables`
Der Wert von x im inneren Gültigkeitsbereich ist: 12
Der Wert von x ist: 6

Verschatten unterscheidet sich vom Markieren einer Variable mit mut, weil wir einen Kompilierfehler erhalten, wenn wir versehentlich versuchen, diese Variable neu zuzuweisen, ohne das Schlüsselwort let zu verwenden. Durch das Verwenden von let können wir einige wenige Transformationen an einem Wert durchführen, aber die Variable ist unveränderbar, nachdem diese Transformationen abgeschlossen sind.

Der andere Unterschied zwischen mut und Verschatten besteht darin, dass wir, weil wir effektiv eine neue Variable erstellen, wenn wir das Schlüsselwort let erneut verwenden, den Typ des Wertes ändern können, aber denselben Namen wiederverwenden. Nehmen wir zum Beispiel an, unser Programm bittet einen Benutzer, durch Eingeben von Leerzeichen zu zeigen, wie viele Leerzeichen er zwischen irgendeinem Text haben möchte, und wir möchten diese Eingabe als Zahl speichern:

#![allow(unused)]
fn main() {
let spaces = "   ";
let spaces = spaces.len();
}

Die erste Variable spaces ist ein String-Typ und die zweite Variable spaces ist ein Zahlentyp Integer. Das Verschatten erspart es uns also, uns verschiedene Namen auszudenken, z.B. spaces_str und spaces_num; stattdessen können wir den einfacheren Namen spaces wiederverwenden. Wenn wir jedoch versuchen, dafür mut zu verwenden, wie hier gezeigt, erhalten wir einen Kompilierfehler:

#![allow(unused)]
fn main() {
let mut spaces = "   ";
spaces = spaces.len();

}

Der Fehler besagt, dass es uns nicht erlaubt ist, den Typ einer Variable zu mutieren:

$ cargo run
   Compiling variables v0.1.0 (file:///projects/variables)
error[E0308]: mismatched types
 --> src/main.rs:3:14
  |
2 |     let mut spaces = "   ";
  |                      ----- expected due to this value
3 |     spaces = spaces.len();
  |              ^^^^^^^^^^^^ expected `&str`, found `usize`
  |
help: try removing the method call
  |
3 -     spaces = spaces.len();
3 +     spaces = spaces;
  |

For more information about this error, try `rustc --explain E0308`.
error: could not compile `variables` (bin "variables") due to 1 previous error

Nachdem wir nun untersucht haben, wie Variablen funktionieren, wollen wir uns weitere Datentypen ansehen, die sie haben können.

Datentypen

Jeder Wert in Rust ist von einem bestimmten Datentyp, der Rust mitteilt, welche Art von Daten angegeben wird, damit es weiß, wie es mit diesen Daten arbeiten soll. Wir werden uns zwei Datentyp-Untermengen ansehen: Skalar (scalar) und Verbund (compound).

Denk daran, dass Rust eine statisch typisierte Sprache ist, was bedeutet, dass es die Typen von allen Variablen zur Kompilierzeit kennen muss. Der Compiler kann normalerweise auf der Grundlage des Wertes und wie wir ihn verwenden ableiten, welchen Typ wir verwenden wollen. Wenn mehrere Typen möglich sind, wie zum Beispiel als wir im Abschnitt „Vergleichen der Schätzung mit der Geheimzahl“ eine Zeichenkette (String) mittels parse zu einem numerischen Typ umwandelten, müssen wir eine Typ-Annotation ergänzen, wie hier:

#![allow(unused)]
fn main() {
let guess: u32 = "42".parse().expect("Keine Zahl!");
}

Wenn wir diese Typ-Annotation nicht angeben, zeigt Rust den folgenden Fehler an, was bedeutet, dass der Compiler mehr Informationen von uns benötigt, um zu wissen welchen Typ wir verwenden wollen:

$ cargo build
   Compiling no_type_annotations v0.1.0 (file:///projects/no_type_annotations)
error[E0284]: type annotations needed
 --> src/main.rs:2:9
  |
2 |     let guess = "42".parse().expect("Keine Zahl!");
  |         ^^^^^        ----- type must be known at this point
  |
  = note: cannot satisfy `<_ as FromStr>::Err == _`
help: consider giving `guess` an explicit type
  |
2 |     let guess: /* Type */ = "42".parse().expect("Keine Zahl!");
  |              ++++++++++++

For more information about this error, try `rustc --explain E0284`.
error: could not compile `no_type_annotations` (bin "no_type_annotations") due to 1 previous error

Für andere Datentypen wirst du andere Typ-Annotationen sehen.

Skalare Typen

Ein skalarer Typ stellt einen einzelnen Wert dar. Rust hat vier primäre skalare Typen: Ganze Zahlen, Fließkommazahlen, boolesche Werte (Wahrheitswerte) und Zeichen. Du erkennst diese vielleicht aus anderen Programmiersprachen. Lass uns darüber sprechen, wie sie in Rust funktionieren.

Ganzzahl-Typen

Eine ganze Zahl ist eine Zahl ohne Bruchteilkomponente. Wir verwendeten eine ganze Zahl in Kapitel 2, den Typ u32. Diese Typdeklaration gibt an, dass der Wert, dem sie zugeordnet ist, eine 32 Bit große ganze Zahl ohne Vorzeichen ist (vorzeichenbehaftete Ganzzahl-Typen beginnen mit i anstatt u). Tabelle 3-1 zeigt die in Rust eingebauten Ganzzahl-Typen. Wir können jede dieser Varianten verwenden, um den Typ eines ganzzahligen Wertes zu deklarieren.

Tabelle 3-1: Ganzzahlige Typen in Rust

Jede Variante kann entweder vorzeichenbehaftet oder vorzeichenlos sein und hat eine explizite Größe. Vorzeichenbehaftet (signed) und vorzeichenlos (unsigned) beziehen sich darauf, ob es möglich ist, dass die Zahl negativ ist – in anderen Worten, ob die Zahl ein Vorzeichen haben muss (vorzeichenbehaftet) oder ob sie immer nur positiv sein wird und daher ohne Vorzeichen dargestellt werden kann (vorzeichenlos). Es ist wie das Schreiben von Zahlen auf Papier: Wenn das Vorzeichen eine Rolle spielt, wird die Zahl mit einem Plus- oder Minuszeichen geschrieben; wenn man jedoch davon ausgehen kann, dass die Zahl positiv ist, wird sie ohne Vorzeichen geschrieben. Vorzeichenbehaftete Zahlen werden unter Verwendung der Zweierkomplementdarstellung gespeichert.

Jede vorzeichenbehaftete Variante kann Zahlen von -(2^{n - 1}) bis einschließlich 2^{n - 1} - 1 speichern, wobei n die Anzahl an Bits ist, die diese Variante benutzt. Ein i8 kann also Zahlen von -(2⁷) bis 2⁷ - 1 speichern, was -128 bis 127 entspricht. Vorzeichenlose Varianten können Zahlen von 0 bis 2ⁿ - 1 speichern, also kann ein u8 Zahlen von 0 bis 2⁸ - 1 speichern, was 0 bis 255 entspricht.

Zusätzlich hängen die Typen isize und usize von der Architektur des Computers ab, auf dem dein Programm läuft, die in der Tabelle als „arch“ bezeichnet wird: 64 Bit wenn du dich auf einer 64-Bit-Architektur befindest und 32 Bit auf einer 32-Bit-Architektur.

Du kannst ganzzahlige Literale in jeder der in Tabelle 3-2 gezeigten Formen schreiben. Beachte, dass Zahlenliterale, die mehrere numerische Typen sein können, ein Typ-Suffix wie 57u8 zur Bezeichnung des Typs erlauben. Zahlenliterale können auch _ als visuelles Trennzeichen verwenden, um die Zahl leichter lesbar zu machen, z.B. 1_000, das den gleichen Wert hat, wie wenn du 1000 angegeben hättest.

Tabelle 3-2: Ganzzahl-Literale in Rust

Woher weist du also, welcher Ganzzahltyp zu verwenden ist? Wenn du dir unsicher bist, sind Rusts Standards im Allgemeinen ein guter Ausgangspunkt: Ganzzahlige Typen sind standardmäßig i32. Die primäre Situation, in der du isize oder usize verwendest, ist beim Indizieren einer Art Sammlung.

Ganzzahlüberlauf

Nehmen wir an, du hast eine Variable vom Typ u8, die Werte zwischen 0 und 255 annehmen kann. Wenn du versuchst, die Variable auf einen Wert außerhalb dieses Bereiches zu ändern, z.B. auf 256, tritt ein Ganzzahlüberlauf auf, was zu einem von zwei Verhaltensweisen führen kann. Wenn du im Fehlersuchmodus (debug mode) kompilierst, fügt Rust Prüfungen auf Ganzzahlüberläufe ein, was dazu führt, dass dein Programm zur Laufzeit abbricht (panic), falls dieses Verhalten auftritt. Rust verwendet den Begriff „panic“, wenn ein Programm durch einen Fehler abgebrochen wird; wir werden Programmabbrüche im Abschnitt „Nicht behebbare Fehler mit panic!“ in Kapitel 9 näher betrachten.

Wenn du mit dem Schalter --release im Freigabemodus (release mode) kompilierst, fügt Rust keine Prüfungen auf Ganzzahlüberläufe, die das Programm abbrechen, ein. Wenn ein Überlauf auftritt, führt Rust stattdessen einen Zweier-Komplement-Umbruch durch. Kurz gesagt, Werte die größer als der Maximalwert den der Typ enthalten kann sind, werden umgebrochen zum kleinsten Wert den der Typ enthalten kann. Im Falle eines u8 wird der Wert 256 zu 0, der Wert 257 zu 1 und so weiter. Das Programm wird nicht abbrechen, aber die Variable wird wahrscheinlich einen anderen Wert annehmen, als du erwartest. Sich auf das Verhalten von Ganzzahlüberläufen zu verlassen wird als Fehler angesehen.

Um die Möglichkeit eines Überlaufs explizit zu behandeln, kannst du diese Methodenfamilien verwenden, die die Standardbibliothek für primitive numerische Typen bereitstellt:

• Umbrechen (wrap) aller Fälle mit den Methoden wrapping_*, z.B. wrapping_add
• Zurückgeben des Wertes None, wenn es einen Überlauf mit einer checked_*-Methode gibt.
• Zurückgeben des Wertes und eines booleschen Wertes, der angibt, ob ein Überlauf mit einer overflowing_*-Methode stattgefunden hat.
• Gewährleisten der Minimal- oder Maximalwerte des Wertes mit den saturating_*-Methoden.

Fließkomma-Typen

Rust hat auch zwei primitive Typen für Fließkommazahlen, das sind Zahlen mit Dezimalkomma. Die Fließkomma-Typen in Rust sind f32 und f64, die 32 Bit bzw. 64 Bit groß sind. Der Standardtyp ist f64, da er auf modernen CPUs ungefähr die gleiche Geschwindigkeit wie f32 hat, aber eine höhere Präzision ermöglicht. Alle Fließkomma-Typen sind vorzeichenbehaftet.

Hier ist ein Beispiel, das Fließkommazahlen in Aktion zeigt:

Dateiname: src/main.rs

fn main() {
    let x = 2.0; // f64

    let y: f32 = 3.0; // f32
}

Fließkommazahlen werden nach dem IEEE-754-Standard dargestellt. Der Typ f32 ist eine Fließkommazahl mit einfacher Genauigkeit und f64 mit doppelter Genauigkeit.

Numerische Operationen

Rust unterstützt grundlegende mathematische Operationen, die man bei allen Zahlentypen erwartet: Addition, Subtraktion, Multiplikation, Division und Restberechnung. Die Ganzzahldivision rundet auf die nächste Ganzzahl ab. Der folgende Code zeigt, wie du die einzelnen Typen in einer let-Anweisung verwenden würdest:

Dateiname: src/main.rs

fn main() {
    // Addition
    let sum = 5 + 10;

    // Subtraktion
    let difference = 95.5 - 4.3;

    // Multiplikation
    let product = 4 * 30;

    // Division
    let quotient = 56.7 / 32.2;
    let truncated = -5 / 3; // Ergibt -1

    // Restberechnung
    let remainder = 43 % 5;
}

Jeder Ausdruck in diesen Anweisungen verwendet einen mathematischen Operator und wird zu einem einzelnen Wert ausgewertet, der dann an eine Variable gebunden wird. Anhang B enthält eine Liste aller Operatoren, die Rust anbietet.

Der boolesche Typ

Wie in den meisten anderen Programmiersprachen hat ein boolescher Typ in Rust zwei mögliche Werte: true (wahr) und false (falsch). Boolesche Werte sind ein Byte groß. In Rust wird der boolesche Typ mit bool spezifiziert. Zum Beispiel:

Dateiname: src/main.rs

fn main() {
    let t = true;

    let f: bool = false; // mit expliziter Typ-Annotation
}

Hauptsächlich werden boolesche Werte in Bedingungen verwendet, z.B. im if-Ausdruck. Wie if-Ausdrücke in Rust funktionieren werden wir im Abschnitt „Kontrollfluss“ erläutern.

Der Zeichen-Typ

Rusts Typ char ist der primitivste alphabetische Typ der Sprache. Hier sind einige Beispiele für die Deklaration von char-Werten:

Dateiname: src/main.rs

fn main() {
    let c = 'z';
    let z: char = 'ℤ'; // mit expliziter Typannotation
    let heart_eyed_cat = '😻';
}

Beachte, dass wir char-Literale mit einfachen Anführungszeichen angeben, im Gegensatz zu Zeichenketten-Literalen, die doppelte Anführungszeichen verwenden. Der Typ char von Rust ist vier Bytes groß und stellt einen Unicode-Skalarwert dar, was bedeutet, dass er viel mehr als nur ASCII darstellen kann. Akzentuierte Buchstaben, chinesische, japanische und koreanische Zeichen, Emoji und Leerzeichen mit Null-Breite sind gültige char-Werte in Rust. Unicode-Skalarwerte reichen von U+0000 bis U+D7FF und von U+E000 bis einschließlich U+10FFFF. Ein „Zeichen“ ist jedoch nicht wirklich ein Konzept in Unicode, deine menschliche Intuition dafür, was ein „Zeichen“ ist, stimmt möglicherweise nicht mit dem überein, was ein char in Rust ist. Wir werden dieses Thema in „UTF-8-kodierten Text in Zeichenketten (strings) ablegen“ in Kapitel 8 im Detail besprechen.

Verbund-Typen

Verbund-Typen (compound types) können mehrere Werte zu einem Typ gruppieren. Rust hat zwei primitive Verbund-Typen: Tupel (tuples) und Arrays (arrays).

Der Tupel-Typ

Ein Tupel ist eine allgemeine Möglichkeit, eine Reihe von Werten mit einer Vielzahl von Typen zu einem Verbund-Typ zusammenzufassen. Tupel haben eine feste Länge: Einmal deklariert, können sie weder wachsen noch schrumpfen.

Wir erzeugen ein Tupel, indem wir eine durch Kommata getrennte Liste von Werten innerhalb von Klammern schreiben. Jede Position im Tupel hat einen Typ und die Typen der verschiedenen Werte im Tupel müssen nicht gleich sein. In diesem Beispiel haben wir optionale Typ-Annotationen angegeben:

Dateiname: src/main.rs

fn main() {
    let tup: (i32, f64, u8) = (500, 6.4, 1);
}

Die Variable tup bindet das gesamte Tupel, da ein Tupel als ein einziges Verbundelement betrachtet wird. Um die einzelnen Werte aus einem Tupel herauszubekommen, können wir den Musterabgleich verwenden, um einen Tupelwert zu destrukturieren, etwa so:

Dateiname: src/main.rs

fn main() {
    let tup = (500, 6.4, 1);

    let (x, y, z) = tup;

    println!("Der Wert von y ist: {y}");
}

Dieses Programm erzeugt zunächst ein Tupel und bindet es an die Variable tup. Dann benutzt es ein Muster mit let, um tup zu nehmen und in drei separate Variablen x, y und z umzuwandeln. Dies nennt man destrukturieren (destructuring), weil es das einzelne Tupel in drei Teile zerlegt. Schließlich gibt das Programm den Wert von y aus, der 6.4 ist.

Wir können direkt auf ein Tupelelement zugreifen, indem wir einen Punkt (.) gefolgt vom Index des Wertes, auf den wir zugreifen wollen, verwenden. Zum Beispiel:

Dateiname: src/main.rs

fn main() {
    let x: (i32, f64, u8) = (500, 6.4, 1);

    let five_hundred = x.0;

    let six_point_four = x.1;

    let one = x.2;
}

Dieses Programm erstellt das Tupel x und greift dann auf jedes Element des Tupels über die jeweiligen Indizes zu. Wie bei den meisten Programmiersprachen ist der erste Index in einem Tupel 0.

Das Tupel ohne Werte hat einen speziellen Namen: Einheitswert (unit value). Dieser Wert und der zugehörige Typ (Einheitstyp (unit type)) werden beide mit () geschrieben und stellen einen leeren Wert oder einen leeren Rückgabetyp dar. Ausdrücke geben implizit den Einheitswert zurück, wenn sie keinen anderen Wert zurückgeben.

Der Array-Typ

Eine andere Möglichkeit, eine Kollektion mit mehreren Werten zu haben, ist mit einem Array. Im Gegensatz zu einem Tupel muss jedes Element eines Arrays den gleichen Typ haben. Anders als Arrays in einigen anderen Sprachen haben Arrays in Rust eine feste Länge.

Wir schreiben die Werte in einem Array als kommagetrennte Liste in eckigen Klammern:

Dateiname: src/main.rs

fn main() {
    let a = [1, 2, 3, 4, 5];
}

Arrays sind nützlich, wenn du deine Daten eher auf dem Stapelspeicher als im Haldenspeicher abgelegt haben möchtest (auf den Stapelspeicher und den Haldenspeicher gehen wir in Kapitel 4 näher ein) oder wenn du sicherstellen willst, dass du immer eine feste Anzahl von Elementen hast. Ein Array ist jedoch nicht so flexibel wie der Vektortyp. Ein Vektor ist ein ähnlicher Kollektionstyp, der von der Standardbibliothek zur Verfügung gestellt wird und der in seiner Größe wachsen oder schrumpfen kann. Wenn du dir nicht sicher bist, ob du ein Array oder einen Vektor verwenden sollst, ist es wahrscheinlich, dass du einen Vektor verwenden solltest. In Kapitel 8 werden Vektoren ausführlicher besprochen.

Arrays sind jedoch hilfreicher, wenn du weißt, dass sich die Anzahl der Elemente nicht ändern wird. Wenn du z.B. die Monatsnamen in einem Programm verwendest, würdest du wahrscheinlich eher ein Array als einen Vektor verwenden, weil du weißt, dass es immer 12 Elemente enthalten wird:

#![allow(unused)]
fn main() {
let months = ["Januar", "Februar", "März", "April", "Mai", "Juni", "Juli",
              "August", "September", "Oktober", "November", "Dezember"];
}

Der Typ eines Arrays wird in eckigen Klammern mit dem Typ der einzelnen Elemente angegeben, ein Semikolon und dann die Anzahl der Elemente im Array, etwa so:

#![allow(unused)]
fn main() {
let a: [i32; 5] = [1, 2, 3, 4, 5];
}

Hier ist i32 der Typ aller Elemente. Nach dem Semikolon gibt die Zahl 5 an, dass das Array fünf Elemente enthält.

Du kannst ein Array auch so initialisieren, dass es für jedes Element denselben Wert enthält, indem du den Anfangswert, gefolgt von einem Semikolon, und dann die Länge des Arrays in eckigen Klammern angibst, wie hier gezeigt:

#![allow(unused)]
fn main() {
let a = [3; 5];
}

Das Array mit dem Namen a wird 5 Elemente enthalten, die alle anfänglich auf den Wert 3 gesetzt werden. Dies ist dasselbe wie das Schreiben von let a = [3, 3, 3, 3, 3];, aber in einer prägnanteren Weise.

Zugriff auf Array-Elemente

Ein Array ist ein einzelner Speicherbereich mit einer bekannten, festen Größe, der auf den Stapelspeicher gelegt wird. Du kannst auf Elemente eines Arrays mit Hilfe der Indizierung wie folgt zugreifen:

Dateiname: src/main.rs

fn main() {
    let a = [1, 2, 3, 4, 5];

    let first = a[0];
    let second = a[1];
}

In diesem Beispiel erhält die Variable mit dem Namen first den Wert 1, weil das der Wert am Index [0] im Array ist. Die Variable mit dem Namen second wird den Wert 2 vom Index [1] im Array erhalten.

Ungültiger Array-Element-Zugriff

Sehen wir uns an was passiert, wenn du versuchst, auf ein Element eines Arrays zuzugreifen, das sich hinter dem Ende des Arrays befindet. Angenommen, du führst diesen Code aus, ähnlich zum Ratespiel in Kapitel 2, um einen Array-Index vom Benutzer zu erhalten:

Dateiname: src/main.rs

use std::io;

fn main() {
    let a = [1, 2, 3, 4, 5];

    println!("Bitte gib einen Array-Index ein.");

    let mut index = String::new();

    io::stdin()
        .read_line(&mut index)
        .expect("Fehler beim Lesen der Zeile");

    let index: usize = index
        .trim()
        .parse()
        .expect("Eingegebener Index war keine Zahl");

    let element = a[index];

    println!(
        "Der Wert von element beim Index {index} ist: {element}");
}

Dieser Code kompiliert erfolgreich. Wenn du diesen Code mit cargo run ausführst und 0, 1, 2, 3 oder 4 eingibst, wird das Programm den entsprechenden Wert an diesem Index im Array ausgeben. Wenn du stattdessen eine Zahl hinter dem Ende des Arrays eingibst, z.B. 10, erhältst du eine Ausgabe wie diese:

thread 'main' panicked at src/main.rs:19:19:
index out of bounds: the len is 5 but the index is 10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Das Programm führte zu einem Laufzeitfehler an der Stelle, an der ein ungültiger Wert in der Index-Operation verwendet wurde. Das Programm wurde mit einer Fehlermeldung beendet und hat die abschließende println!-Anweisung nicht ausgeführt. Wenn du versuchst, mit Hilfe der Indizierung auf ein Element zuzugreifen, prüft Rust, ob der angegebene Index kleiner als die Array-Länge ist. Wenn der Index größer oder gleich der Länge ist, wird Rust das Programm abbrechen. Diese Prüfung muss zur Laufzeit erfolgen, insbesondere in diesem Fall, weil der Compiler unmöglich wissen kann, welchen Wert ein Benutzer später eingeben wird, wenn er den Code ausführt.

Dies ist ein Beispiel für die Umsetzung der Speichersicherheitsprinzipien von Rust. In vielen Low-Level-Sprachen wird diese Art der Überprüfung nicht durchgeführt und wenn du einen falschen Index angibst, kann auf ungültigen Speicher zugegriffen werden. Rust schützt dich vor dieser Art von Fehlern, indem es das Programm sofort beendet, anstatt den Speicherzugriff zuzulassen und fortzusetzen. Kapitel 9 behandelt die Fehlerbehandlung in Rust und wie du lesbaren, sicheren Code schreiben kannst, der weder abstürzt noch ungültige Speicherzugriffe zulässt.

Funktionen

Funktionen sind im Rust-Code weit verbreitet. Du hast bereits eine der wichtigsten Funktionen in der Sprache gesehen: Die Funktion main, die der Einstiegspunkt vieler Programme ist. Du hast auch das Schlüsselwort fn gesehen, mit dem du neue Funktionen deklarieren kannst.

Rust-Code verwendet die Schlangenschrift-Stil-Konvention (snake case) für Funktions- und Variablennamen, bei der alle Buchstaben klein geschrieben sind und Unterstriche Wörter separieren. Hier ist ein Programm, das eine Beispiel-Funktionsdefinition enthält:

Dateiname: src/main.rs

fn main() {
    println!("Hallo Welt!");

    another_function();
}

fn another_function() {
    println!("Eine andere Funktion.");
}

Wir definieren eine Funktion in Rust durch die Eingabe von fn, gefolgt von einem Funktionsnamen und einem Satz Klammern. Die geschweiften Klammern teilen dem Compiler mit, wo der Funktionsrumpf beginnt und endet.

Wir können jede Funktion, die wir definiert haben, aufrufen, indem wir ihren Namen gefolgt von einem Satz Klammern eingeben. Da another_function im Programm definiert ist, kann sie von innerhalb der main-Funktion aufgerufen werden. Beachte, dass wir another_function nach der main-Funktion im Quellcode definiert haben; wir hätten sie auch vorher definieren können. Rust interessiert es nicht, wo du deine Funktionen definierst, nur dass sie irgendwo definiert sind.

Lass uns ein neues Binärprojekt namens „functions“ anfangen, um Funktionen weiter zu erforschen. Platziere das Beispiel another_function in src/main.rs und lass es laufen. Du solltest die folgende Ausgabe sehen:

$ cargo run
   Compiling functions v0.1.0 (file:///projects/functions)
    Finished dev [unoptimized + debuginfo] target(s) in 0.28s
     Running `target/debug/functions`
Hallo Welt!
Eine andere Funktion.

Die Zeilen werden in der Reihenfolge ausgeführt, in der sie in der main-Funktion erscheinen. Zuerst wird die Nachricht „Hallo Welt!“ ausgegeben und dann wird another_function aufgerufen und ihre Nachricht ausgegeben.

Parameter

Wir können Funktionen auch so definieren, dass sie Parameter haben, das sind spezielle Variablen, die Teil der Funktionssignatur sind. Wenn eine Funktion Parameter hat, kannst du sie mit konkreten Werten für diese Parameter versehen. Technisch gesehen werden die konkreten Werte Argumente genannt, aber in lockeren Gesprächen neigen Leute dazu, die Worte Parameter und Argument entweder für die Variablen in der Definition einer Funktion oder für die konkreten Werte, die beim Aufruf einer Funktion übergeben werden, synonym zu verwenden.

In dieser Version von another_function fügen wir einen Parameter hinzu:

Dateiname: src/main.rs

fn main() {
    another_function(5);
}

fn another_function(x: i32) {
    println!("Der Wert von x ist: {x}");
}

Versuche, dieses Programm auszuführen; du solltest die folgende Ausgabe erhalten:

$ cargo run
   Compiling functions v0.1.0 (file:///projects/functions)
    Finished dev [unoptimized + debuginfo] target(s) in 1.21s
     Running `target/debug/functions`
Der Wert von x ist: 5

Die Deklaration another_function hat einen Parameter namens x. Der Typ von x wird als i32 angegeben. Wenn wir 5 an another_function übergeben, setzt das Makro println! den Wert 5 an die Stelle, an der sich das Paar geschweifter Klammern mit dem x darin in der Formatierungszeichenkette befand.

In Funktionssignaturen musst du den Typ jedes Parameters deklarieren. Dies ist eine bewusste Designentscheidung von Rust: Das Erfordernis von Typ-Annotationen in Funktionsdefinitionen bedeutet, dass der Compiler sie fast nie an anderer Stelle im Code benötigt, um herauszufinden, welchen Typ du meinst. Der Compiler ist auch in der Lage, hilfreichere Fehlermeldungen zu geben, wenn er weiß, welche Typen die Funktion erwartet.

Wenn wir mehrere Parameter definieren, trennen wir die Parameterdeklarationen mit Kommas, so wie hier:

Dateiname: src/main.rs

fn main() {
    print_labeled_measurement(5, 'h');
}

fn print_labeled_measurement(value: i32, unit_label: char) {
    println!("Das Maß ist: {value}{unit_label}");
}

Dieses Beispiel erzeugt eine Funktion namens print_labeled_measurement mit zwei Parametern. Der erste Parameter heißt value und ist ein i32. Der zweite heißt unit_label und ist vom Typ char. Die Funktion gibt dann einen Text aus, der sowohl value als auch unit_label enthält.

Lass uns versuchen, diesen Code auszuführen. Ersetze das Programm, das sich derzeit in der Datei src/main.rs deines „functions“-Projekts befindet, durch das vorhergehende Beispiel und führe es mit cargo run aus:

$ cargo run
   Compiling functions v0.1.0 (file:///projects/functions)
    Finished dev [unoptimized + debuginfo] target(s) in 0.31s
     Running `target/debug/functions`
Das Maß ist: 5h

Da wir die Funktion mit 5 als Wert für value und 'h' als Wert für unit_label aufgerufen haben, enthält die Programmausgabe diese Werte.

Anweisungen und Ausdrücke

Funktionsrümpfe bestehen aus einer Reihe von Anweisungen, die optional mit einem Ausdruck enden können. Bisher haben wir nur Funktionen ohne einen endenden Ausdruck behandelt, aber du hast einen Ausdruck als Teil einer Anweisung gesehen. Da Rust eine auf Ausdrücken basierende Sprache ist, ist dies eine wichtige Unterscheidung, die es zu verstehen gilt. Andere Sprachen haben nicht dieselben Unterscheidungen, deshalb wollen wir uns ansehen, was Anweisungen und Ausdrücke sind und wie sich ihre Unterschiede auf die Funktionsrümpfe auswirken.

• Anweisungen (statements) sind Instruktionen, die eine Aktion ausführen und keinen Wert zurückgeben.
• Ausdrücke (expressions) werden zu einem Ergebniswert ausgewertet. Schauen wir uns einige Beispiele an.

Eine Variable zu erstellen und ihr mit dem Schlüsselwort let einen Wert zuzuweisen, ist eine Anweisung. In Codeblock 3-1 ist let y = 6; eine Anweisung.

Dateiname: src/main.rs

fn main() {
    let y = 6;
}

Codeblock 3-1: Eine Funktionsdeklaration main, die eine Anweisung enthält

Auch Funktionsdefinitionen sind Anweisungen; das gesamte vorhergehende Beispiel ist eine Anweisung für sich.

Anweisungen geben keine Werte zurück. Daher kannst du keine let-Anweisung einer anderen Variablen zuweisen, wie es der folgende Code versucht; du wirst einen Fehler erhalten:

Dateiname: src/main.rs

fn main() {
    let x = (let y = 6);
}

Wenn du dieses Programm ausführst, wirst du in etwa folgenden Fehler erhalten:

$ cargo run
   Compiling functions v0.1.0 (file:///projects/functions)
error: expected expression, found `let` statement
 --> src/main.rs:2:14
  |
2 |     let x = (let y = 6);
  |              ^^^
  |
  = note: only supported directly in conditions of `if` and `while` expressions

warning: unnecessary parentheses around assigned value
 --> src/main.rs:2:13
  |
2 |     let x = (let y = 6);
  |             ^         ^
  |
  = note: `#[warn(unused_parens)]` on by default
help: remove these parentheses
  |
2 -     let x = (let y = 6);
2 +     let x = let y = 6;
  |

warning: `functions` (bin "functions") generated 1 warning
error: could not compile `functions` (bin "functions") due to 1 previous error; 1 warning emitted

Die Anweisung let y = 6 gibt keinen Wert zurück, also gibt es für x nichts, woran x gebunden werden kann. Dies unterscheidet sich von dem, was in anderen Sprachen wie C und Ruby geschieht, wo die Zuweisung den Wert der Zuweisung zurückgibt. In diesen Sprachen kannst du x = y = 6 schreiben und sowohl x als auch y haben den Wert 6; das ist in Rust nicht der Fall.

Ausdrücke werten zu einem Wert aus und machen den größten Teil des restlichen Codes aus, den du in Rust schreiben wirst. Betrachte eine mathematische Operation, z.B. 5 + 6, die ein Ausdruck ist, der zum Wert 11 ausgewertet wird. Ausdrücke können Teil von Anweisungen sein: In Codeblock 3-1 ist die 6 in der Anweisung let y = 6; ein Ausdruck, der den Wert 6 ergibt. Der Aufruf einer Funktion ist ein Ausdruck. Der Aufruf eines Makros ist ein Ausdruck. Ein neuer Gültigkeitsbereichsblock, der mit geschweiften Klammern erstellt wird, ist ein Ausdruck, zum Beispiel:

Dateiname: src/main.rs

fn main() {
    let y = {
        let x = 3;
        x + 1
    };

    println!("Der Wert von y ist: {y}");
}

Der Ausdruck

{
    let x = 3;
    x + 1
}

ist ein Block, der in diesem Fall zu 4 ausgewertet wird. Dieser Wert wird als Teil der let-Anweisung an y gebunden. Beachte, dass die Zeile x + 1 am Ende kein Semikolon hat, was sich von den meisten Zeilen, die du bisher gesehen hast, unterscheidet. Ausdrücke enthalten keine abschließenden Semikolons. Wenn du ein Semikolon an das Ende eines Ausdrucks anfügst, machst du daraus eine Anweisung, und sie gibt keinen Wert zurück. Behalte dies im Hinterkopf, wenn du als nächstes die Rückgabewerte von Funktionen und Ausdrücken untersuchst.

Funktionen mit Rückgabewerten

Funktionen können Werte an den Code zurückgeben, der sie aufruft. Wir benennen keine Rückgabewerte, aber wir müssen ihren Typ nach einem Pfeil (->) deklarieren. In Rust ist der Rückgabewert der Funktion gleichbedeutend mit dem Wert des letzten Ausdrucks im Block des Funktionsrumpfs. Du kannst frühzeitig von einer Funktion zurückkehren, indem du das Schlüsselwort return verwendest und einen Wert angibst, aber die meisten Funktionen geben den letzten Ausdruck implizit zurück. Hier ist ein Beispiel für eine Funktion, die einen Wert zurückgibt:

Dateiname: src/main.rs

fn five() -> i32 {
    5
}

fn main() {
    let x = five();

    println!("Der Wert von x ist: {x}");
}

Es gibt keine Funktionsaufrufe, Makros oder gar let-Anweisungen in der five-Funktion – nur die Zahl 5 selbst. Das ist eine vollkommen gültige Funktion in Rust. Beachte, dass der Rückgabetyp der Funktion ebenfalls angegeben ist, mit -> i32. Versuche diesen Code auszuführen; die Ausgabe sollte wie folgt aussehen:

$ cargo run
   Compiling functions v0.1.0 (file:///projects/functions)
    Finished dev [unoptimized + debuginfo] target(s) in 0.30s
     Running `target/debug/functions`
Der Wert von x ist: 5

Die 5 in five ist der Rückgabewert der Funktion, weshalb der Rückgabetyp i32 ist. Lass uns dies genauer untersuchen. Es gibt zwei wichtige Teile: Erstens zeigt die Zeile let x = five();, dass wir den Rückgabewert einer Funktion verwenden, um eine Variable zu initialisieren. Da die Funktion five den Wert 5 zurückgibt, ist diese Zeile die gleiche wie die folgende:

#![allow(unused)]
fn main() {
let x = 5;
}

Zweitens hat die Funktion five keine Parameter und definiert den Typ des Rückgabewertes, aber der Funktionsrumpf ist eine einsame 5 ohne Semikolon, weil es ein Ausdruck ist, dessen Wert wir zurückgeben wollen.

Sehen wir uns ein weiteres Beispiel an:

Dateiname: src/main.rs

fn main() {
    let x = plus_one(5);

    println!("Der Wert von x ist: {x}");
}

fn plus_one(x: i32) -> i32 {
    x + 1
}

Beim Ausführen dieses Codes wird Der Wert von x ist: 6 ausgegeben. Wenn wir aber ein Semikolon an das Ende der Zeile mit x + 1 setzen und es von einem Ausdruck in eine Anweisung ändern, erhalten wir einen Fehler:

Dateiname: src/main.rs

fn main() {
    let x = plus_one(5);

    println!("Der Wert von x ist: {x}");
}

fn plus_one(x: i32) -> i32 {
    x + 1;
}

Das Kompilieren dieses Codes führt zum folgenden Fehler:

$ cargo run
   Compiling functions v0.1.0 (file:///projects/functions)
error[E0308]: mismatched types
 --> src/main.rs:7:24
  |
7 | fn plus_one(x: i32) -> i32 {
  |    --------            ^^^ expected `i32`, found `()`
  |    |
  |    implicitly returns `()` as its body has no tail or `return` expression
8 |     x + 1;
  |          - help: remove this semicolon to return this value

For more information about this error, try `rustc --explain E0308`.
error: could not compile `functions` (bin "functions") due to 1 previous error

Die Hauptfehlermeldung mismatched types offenbart das Kernproblem dieses Codes. Die Definition der Funktion plus_one besagt, dass sie ein i32 zurückgibt, aber Anweisungen werden nicht zu einem Wert ausgewertet, was durch den Einheitstyp () ausgedrückt wird. Daher wird nichts zurückgegeben, was der Funktionsdefinition widerspricht und zu einem Fehler führt. In dieser Ausgabe gibt Rust eine Meldung aus, die möglicherweise helfen kann, dieses Problem zu beheben: Es wird vorgeschlagen, das Semikolon zu entfernen, was den Fehler beheben würde.

Kommentare

Alle Programmierer bemühen sich, ihren Code leicht verständlich zu machen, aber manchmal sind zusätzliche Erklärungen angebracht. In solchen Fällen versehen Entwickler den Quellcode mit Kommentaren, welche der Compiler ignoriert und für andere Entwickler nützlich sein können.

Dies ist ein einfacher Kommentar:

#![allow(unused)]
fn main() {
// Hallo Welt
}

In Rust beginnt ein gewöhnlicher Kommentar mit zwei Schrägstrichen; der Kommentar reicht dann bis zum Ende der Zeile. Für Kommentare, die über eine einzelne Zeile hinausgehen, musst du bei jedem Zeilenanfang // angeben:

#![allow(unused)]
fn main() {
// Hier passiert etwas kompliziertes, so komplex dass wir
// mehrere Kommentarzeilen brauchen! Puh! Hoffentlich erklärt
// dieser Kommentar, was hier passiert.
}

Kommentare können auch am Ende einer Codezeile stehen:

Dateiname: src/main.rs

fn main() {
    let lucky_number = 7; // Heute habe ich Glück
}

Gängiger ist jedoch die Schreibweise mit dem Kommentar über der Codezeile, die er beschreibt:

Dateiname: src/main.rs

fn main() {
    // Heute habe ich Glück
    let lucky_number = 7;
}

Rust kennt noch eine weitere Kommentarart, nämlich Dokumentationskommentare, die wir im Abschnitt „Kisten (crate) auf crates.io veröffentlichen“ in Kapitel 14 besprechen werden.

Kontrollfluss

Die Fähigkeit, Code auszuführen, der davon abhängt, ob eine Bedingung true ist, oder Code wiederholt auszuführen, während eine Bedingung true ist, sind grundlegende Bausteine der meisten Programmiersprachen. Die gebräuchlichsten Konstrukte, mit denen du den Kontrollfluss von Rust-Code kontrollieren kannst, sind if-Ausdrücke und Schleifen.

if-Ausdrücke

Ein if-Ausdruck erlaubt es dir, deinen Code abhängig von Bedingungen zu verzweigen. Du gibst eine Bedingung an und legst dann fest: „Wenn diese Bedingung erfüllt ist, führe diesen Codeblock aus. Wenn die Bedingung nicht erfüllt ist, darf dieser Codeblock nicht ausgeführt werden.“

Erstelle in deinem projects-Verzeichnis ein neues Projekt namens branches, um den if-Ausdruck zu erforschen. Gibt in der Datei src/main.rs folgendes ein:

Dateiname: src/main.rs

fn main() {
    let number = 3;

    if number < 5 {
        println!("Bedingung war wahr");
    } else {
        println!("Bedingung war falsch");
    }
}

Alle if-Ausdrücke beginnen mit dem Schlüsselwort if, gefolgt von einer Bedingung. In diesem Fall prüft die Bedingung, ob die Variable number einen Wert kleiner als 5 hat oder nicht. Der Codeblock, den wir ausführen wollen, wenn die Bedingung true ist, wird unmittelbar nach der Bedingung in geschweifte Klammern gesetzt. Codeblöcke, die mit den Bedingungen in if-Ausdrücken verbunden sind, werden manchmal auch als Zweige (arms) bezeichnet, genau wie die Zweige in match-Ausdrücken, die wir im Abschnitt „Vergleichen der Schätzung mit der Geheimzahl“ in Kapitel 2 besprochen haben.

Optional können wir auch einen else-Ausdruck angeben, was wir hier gemacht haben, um dem Programm einen alternativen Codeblock zur Ausführung zu geben, falls die Bedingung zu false ausgewertet wird. Wenn du keinen else-Ausdruck angibst und die Bedingung false ist, überspringt das Programm einfach den if-Block und geht zum nächsten Codeteil über.

Versuche, diesen Code auszuführen; du solltest die folgende Ausgabe sehen:

$ cargo run
   Compiling branches v0.1.0 (file:///projects/branches)
    Finished dev [unoptimized + debuginfo] target(s) in 0.31s
     Running `target/debug/branches`
Bedingung war wahr

Lass uns versuchen, den Wert von number in einen Wert zu ändern, der die Bedingung falsch macht, um zu sehen, was passiert:

fn main() {
    let number = 7;

    if number < 5 {
        println!("Bedingung war wahr");
    } else {
        println!("Bedingung war falsch");
    }
}

Führe das Programm erneut aus und sieh dir die Ausgabe an:

$ cargo run
   Compiling branches v0.1.0 (file:///projects/branches)
    Finished dev [unoptimized + debuginfo] target(s) in 0.31s
     Running `target/debug/branches`
Bedingung war falsch

Es ist auch erwähnenswert, dass die Bedingung in diesem Code ein bool sein muss. Wenn die Bedingung kein bool ist, erhalten wir einen Fehler. Versuche zum Beispiel, den folgenden Code auszuführen:

Dateiname: src/main.rs

fn main() {
    let number = 3;

    if number {
        println!("Zahl war drei");
    }
}

Die if-Bedingung wird diesmal zum Wert 3 ausgewertet und Rust wirft einen Fehler:

$ cargo run
   Compiling branches v0.1.0 (file:///projects/branches)
error[E0308]: mismatched types
 --> src/main.rs:4:8
  |
4 |     if number {
  |        ^^^^^^ expected `bool`, found integer

For more information about this error, try `rustc --explain E0308`.
error: could not compile `branches` (bin "branches") due to 1 previous error

Der Fehler gibt an, dass Rust ein bool erwartet, aber eine ganze Zahl erhalten hat. Im Gegensatz zu Sprachen wie Ruby und JavaScript wird Rust nicht automatisch versuchen, nicht-boolsche Typen in ein Boolean zu konvertieren. Du musst explizit sein und immer if mit einer Booleschen Bedingung versehen. Wenn wir beispielsweise wollen, dass der if-Codeblock nur ausgeführt wird, wenn eine Zahl ungleich 0 ist, können wir den if-Ausdruck wie folgt ändern:

Dateiname: src/main.rs

fn main() {
    let number = 3;

    if number != 0 {
        println!("Zahl war etwas anderes als Null");
    }
}

Wenn du diesen Code ausführst, wird Zahl war etwas anderes als Null ausgegeben.

Behandeln mehrerer Bedingungen mit else if

Du kannst mehrere Bedingungen verwenden, indem du if und else in einem else if-Ausdruck kombinierst. Zum Beispiel:

Dateiname: src/main.rs

fn main() {
    let number = 6;

    if number % 4 == 0 {
        println!("Zahl ist durch 4 teilbar");
    } else if number % 3 == 0 {
        println!("Zahl ist durch 3 teilbar");
    } else if number % 2 == 0 {
        println!("Zahl ist durch 2 teilbar");
    } else {
        println!("Zahl ist nicht durch 4, 3 oder 2 teilbar");
    }
}

Dieses Programm hat vier mögliche Wege, die es nehmen kann. Nachdem du es ausgeführt hast, solltest du folgende Ausgabe sehen:

$ cargo run
   Compiling branches v0.1.0 (file:///projects/branches)
    Finished dev [unoptimized + debuginfo] target(s) in 0.31s
     Running `target/debug/branches`
Zahl ist durch 3 teilbar

Wenn dieses Programm ausgeführt wird, prüft es der Reihe nach jeden if-Ausdruck und führt den ersten Block aus, für den die Bedingung zu true ausgewertet wird. Beachte, dass, obwohl 6 durch 2 teilbar ist, wir weder die Ausgabe Zahl ist durch 2 teilbar sehen, noch sehen wir den Text Zahl ist nicht durch 4, 3 oder 2 teilbar aus dem else-Block. Das liegt daran, dass Rust den Block nur für die erste true-Bedingung ausführt, und wenn es eine findet, prüft es den Rest nicht mehr.

Das Verwenden von zu vielen else if-Ausdrücken kann deinen Code unübersichtlich machen. Wenn du also mehr als einen Ausdruck hast, solltest du deinen Code vielleicht überarbeiten. Kapitel 6 beschreibt ein leistungsfähiges Rust-Verzweigungskonstrukt namens match für solche Fälle.

Verwenden von if in einer let-Anweisung

Weil if ein Ausdruck ist, können wir ihn auf der rechten Seite einer let-Anweisung verwenden, um das Ergebnis einer Variablen zuzuordnen, wie in Codeblock 3-2.

Dateiname: src/main.rs

fn main() {
    let condition = true;
    let number = if condition { 5 } else { 6 };

    println!("Der Wert der Zahl ist: {number}");
}

Codeblock 3-2: Zuweisen des Ergebnisses eines if-Ausdrucks an eine Variable

Die Variable number wird an einen Wert gebunden, der auf dem Ergebnis des if-Ausdrucks basiert. Führe diesen Code aus, um zu sehen, was passiert:

$ cargo run
   Compiling branches v0.1.0 (file:///projects/branches)
    Finished dev [unoptimized + debuginfo] target(s) in 0.30s
     Running `target/debug/branches`
Der Wert der Zahl ist: 5

Denke daran, dass Codeblöcke bis zum letzten Ausdruck in ihnen ausgewertet werden, und auch Zahlen an sich sind Ausdrücke. In diesem Fall hängt der Wert des gesamten if-Ausdrucks davon ab, welcher Codeblock ausgeführt wird. Dies bedeutet, dass die Werte, die potentielle Ergebnisse eines if-Zweigs sein können, vom gleichen Typ sein müssen; in Codeblock 3-2 waren die Ergebnisse sowohl des if-Zweigs als auch des else-Zweigs i32-Ganzzahlen. Wenn die Typen nicht übereinstimmen, wie im folgenden Beispiel, erhalten wir einen Fehler:

Dateiname: src/main.rs

fn main() {
    let condition = true;

    let number = if condition { 5 } else { "sechs" };

    println!("Der Wert der Zahl ist: {number}");
}

Wenn wir versuchen, diesen Code zu kompilieren, erhalten wir einen Fehler. Die if- und else-Zweige haben Werttypen, die inkompatibel sind, und Rust zeigt genau an, wo das Problem im Programm zu finden ist:

$ cargo run
   Compiling branches v0.1.0 (file:///projects/branches)
error[E0308]: `if` and `else` have incompatible types
 --> src/main.rs:4:44
  |
4 |     let number = if condition { 5 } else { "sechs" };
  |                                 -          ^^^^^^^ expected integer, found `&str`
  |                                 |
  |                                 expected because of this

For more information about this error, try `rustc --explain E0308`.
error: could not compile `branches` (bin "branches") due to 1 previous error

Der Ausdruck im if-Block wird zu einer ganzen Zahl und der Ausdruck im else-Block zu einer Zeichenkette ausgewertet. Dies wird nicht funktionieren, da Variablen einen einzigen Typ haben müssen. Rust muss zur Kompilierzeit definitiv wissen, welchen Typ die Variable number hat, damit es zur Kompilierzeit überprüfen kann, ob ihr Typ überall gültig ist, wo wir number verwenden. Rust wäre dazu nicht in der Lage, wenn der Typ von number erst zur Laufzeit bestimmt würde; der Compiler wäre komplexer und würde weniger Garantien über den Code geben, wenn er mehrere hypothetische Typen für jede Variable verfolgen müsste.

Wiederholung mit Schleifen

Es ist oft hilfreich, einen Codeblock mehr als einmal auszuführen. Für diese Aufgabe stellt Rust mehrere Schleifen (loops) zur Verfügung, die den Code innerhalb des Schleifenrumpfs bis zum Ende durchläuft und dann sofort wieder am Anfang beginnt. Um mit Schleifen zu experimentieren, machen wir ein neues Projekt namens loops.

Rust hat drei Arten von Schleifen: loop, while und for. Probieren wir jede einzelne aus.

Wiederholen von Code mit loop

Das Schlüsselwort loop weist Rust an, einen Codeblock immer und immer wieder auszuführen, und zwar für immer oder bis du ihm explizit sagst, dass er aufhören soll.

Als Beispiel änderst du die Datei src/main.rs in deinem loops-Verzeichnis so, dass sie wie folgt aussieht:

Dateiname: src/main.rs

fn main() {
    loop {
        println!("nochmal!");
    }
}

Wenn wir dieses Programm ausführen, werden wir sehen, dass es immer und immer wieder nochmal! ausgibt, bis wir das Programm manuell stoppen. Die meisten Terminals unterstützen das Tastaturkürzel Strg+c, um ein Programm zu unterbrechen, das in einer Endlosschleife feststeckt. Probiere es aus:

$ cargo run
   Compiling loops v0.1.0 (file:///projects/loops)
    Finished dev [unoptimized + debuginfo] target(s) in 0.29s
     Running `target/debug/loops`
nochmal!
nochmal!
nochmal!
nochmal!
^Cnochmal!

Das Symbol ^C steht für die Stelle, an der du Strg+c gedrückt hast. Je nachdem, wo sich der Code in der Schleife befand, als er das Unterbrechungssignal empfing, siehst du nach dem ^C das Wort nochmal! oder nicht.

Glücklicherweise bietet Rust auch eine Möglichkeit, aus einer Schleife mittels Code auszubrechen. Du kannst das Schlüsselwort break innerhalb der Schleife platzieren, um dem Programm mitzuteilen, wann es die Ausführung der Schleife beenden soll. Erinnere dich, dass wir dies im Ratespiel im Abschnitt „Beenden nach einer korrekten Schätzung“ in Kapitel 2 getan haben, um das Programm zu beenden, wenn der Benutzer das Spiel durch Erraten der richtigen Zahl gewonnen hat.

Wir haben im Ratespiel auch continue verwendet, das innerhalb einer Schleife das Programm anweist, jeden restlichen Code in dieser Iteration der Schleife zu überspringen und mit der nächsten Iteration fortzufahren.

Rückgabe von Werten aus Schleifen

Eine der Verwendungen von loop besteht darin, eine Operation, von der du weißt, dass sie fehlschlagen könnte, erneut zu versuchen, z.B. um zu prüfen, ob ein Strang (thread) seine Arbeit abgeschlossen hat. Möglicherweise musst du jedoch das Ergebnis dieser Operation aus der Schleife heraus an den Rest deines Codes weitergeben. Dazu kannst du den Wert, der zurückgegeben werden soll, hinter dem break-Ausdruck angeben, den du zum Beenden der Schleife verwendest; dieser Wert wird aus der Schleife zurückgegeben, sodass du ihn verwenden kannst, wie hier gezeigt:

fn main() {
    let mut counter = 0;

    let result = loop {
        counter += 1;

        if counter == 10 {
            break counter * 2;
        }
    };

    println!("Das Ergebnis ist {result}");
}

Vor der Schleife deklarieren wir eine Variable namens counter und initialisieren sie mit 0. Dann deklarieren wir eine Variable namens result, die den von der Schleife zurückgegebenen Wert enthält. Bei jeder Iteration der Schleife addieren wir 1 zur Variable counter und prüfen dann, ob der Zähler in counter gleich 10 ist. Wenn dies der Fall ist, verwenden wir das Schlüsselwort break mit dem Wert counter * 2. Nach der Schleife verwenden wir ein Semikolon, um die Anweisung zu beenden, die result den Wert zuweist. Schließlich geben wir den Wert in result aus, der in diesem Fall 20 beträgt.

Schleifenlabel zur eindeutigen Unterscheidung mehrerer Schleifen

Wenn du Schleifen innerhalb von Schleifen hast, gelten break und continue für die innerste Schleife an diesem Punkt. Du kannst optional ein Schleifenlabel (loop label) für eine Schleife angeben, das wir dann mit break oder continue verwenden können, um festzulegen, dass diese Schlüsselwörter für die gekennzeichnete Schleife gelten und nicht für die innerste Schleife. Schleifenlabel müssen mit einem einfachen Anführungszeichen beginnen. Hier ist ein Beispiel mit zwei verschachtelten Schleifen:

fn main() {
    let mut count = 0;
    'counting_up: loop {
        println!("Zähler = {count}");
        let mut remaining = 10;

        loop {
            println!("Restliche = {remaining}");
            if remaining == 9 {
                break;
            }
            if count == 2 {
                break 'counting_up;
            }
            remaining -= 1;
        }

        count += 1;
    }
    println!("Zähler-Endstand = {count}");
}

Die äußere Schleife hat das Label 'counting_up und zählt von 0 bis 2 aufwärts. Die innere Schleife ohne Label zählt von 10 bis 9 herunter. Das erste break, das kein Label angibt, beendet nur die innere Schleife. Mit der Anweisung break 'counting_up; wird die äußere Schleife verlassen. Dieser Code gibt folgendes aus:

$ cargo run
   Compiling loops v0.1.0 (file:///projects/loops)
    Finished dev [unoptimized + debuginfo] target(s) in 0.58s
     Running `target/debug/loops`
Zähler = 0
Restliche = 10
Restliche = 9
Zähler = 1
Restliche = 10
Restliche = 9
Zähler = 2
Restliche = 10
Zähler-Endstand = 2

Bedingte Schleifen mit while

Ein Programm wird oft eine Bedingung innerhalb einer Schleife auszuwerten haben. Solange die Bedingung true ist, wird die Schleife durchlaufen. Wenn die Bedingung nicht mehr true ist, ruft das Programm break auf und stoppt die Schleife. Es ist möglich, derartiges Verhalten mittels einer Kombination von loop, if, else und break zu implementieren; du kannst das jetzt in einem Programm versuchen, wenn du möchtest. Dieses Muster ist jedoch so weit verbreitet, dass Rust ein eingebautes Sprachkonstrukt dafür hat, die sogenannte while-Schleife. In Codeblock 3-3 wird while verwendet: Das Programm durchläuft dreimal eine Schleife, in der es jedes Mal abwärts zählt, und dann nach dem Ende der Schleife eine weitere Nachricht ausgibt und sich beendet.

Dateiname: src/main.rs

fn main() {
    let mut number = 3;

    while number != 0 {
        println!("{number}!");

        number -= 1;
    }

    println!("ABHEBEN!!!");
}

Codeblock 3-3: Verwenden einer while-Schleife, um Code auszuführen, solange eine Bedingung wahr ist

Dieses Konstrukt eliminiert eine Menge von Verschachtelungen, die notwendig wären, wenn du loop, if, else und break verwenden würdest, und es ist klarer. Solange eine Bedingung zu true auswertet, läuft der Code ab; andernfalls wird die Schleife verlassen.

Wiederholen anhand einer Kollektion mit for

Du kannst das while-Konstrukt verwenden, um die Elemente einer Kollektion, z.B. ein Array, in einer Schleife zu durchlaufen. Die Schleife in Codeblock 3-4 gibt zum Beispiel jedes Element im Array a aus.

Dateiname: src/main.rs

fn main() {
    let a = [10, 20, 30, 40, 50];
    let mut index = 0;

    while index < 5 {
        println!("Der Wert ist: {}", a[index]);

        index += 1;
    }
}

Codeblock 3-4: Wiederholen anhand aller Elemente einer Kollektion unter Verwendung einer while-Schleife

Hier zählt der Code die Elemente im Array aufwärts. Er beginnt bei Index 0 und wiederholt bis er den letzten Index im Array erreicht (d.h. wenn index < 5 nicht mehr true ist). Wenn du diesen Code ausführst, wird jedes Element im Array ausgegeben:

$ cargo run
   Compiling loops v0.1.0 (file:///projects/loops)
    Finished dev [unoptimized + debuginfo] target(s) in 0.32s
     Running `target/debug/loops`
Der Wert ist: 10
Der Wert ist: 20
Der Wert ist: 30
Der Wert ist: 40
Der Wert ist: 50

Alle fünf Array-Werte erscheinen erwartungsgemäß im Terminal. Wenn index den Wert 5 erreicht hat, stoppt die Schleife ihre Ausführung, bevor sie versucht, einen sechsten Wert aus dem Array zu holen.

Aber dieser Ansatz ist fehleranfällig; wir könnten das Programm zum Abstürzen bringen, wenn der Indexwert oder die Testbedingung falsch ist. Wenn du zum Beispiel die Definition des Arrays a so änderst, dass es vier Elemente hat, aber vergisst, die Bedingung while index < 4 zu aktualisieren, würde der Code abstürzen. Er ist zudem langsam, weil der Compiler Laufzeitcode erzeugt, der die Bedingungsprüfung, ob der Index innerhalb der Arraygrenzen liegt, bei jeder Schleifeniteration durchführt.

Als prägnantere Alternative kannst du eine for-Schleife verwenden und für jedes Element einer Kollektion etwas Code ausführen. Eine for-Schleife sieht wie der Code in Codeblock 3-5 aus.

Dateiname: src/main.rs

fn main() {
    let a = [10, 20, 30, 40, 50];

    for element in a {
        println!("Der Wert ist: {element}");
    }
}

Codeblock 3-5: Wiederholen anhand aller Elemente einer Kollektion unter Verwendung einer for-Schleife

Wenn wir diesen Code ausführen, werden wir die gleiche Ausgabe wie in Codeblock 3-4 sehen. Noch wichtiger ist, dass wir jetzt die Sicherheit des Codes erhöht und die Möglichkeit von Fehlern eliminiert haben, die dadurch entstehen könnten, dass wir über das Ende des Arrays hinausgehen oder nicht weit genug gehen und einige Elemente übersehen.

Wenn du die for-Schleife verwendest, brauchst du nicht daran zu denken, irgendeinen anderen Code zu ändern, wenn du die Anzahl der Werte im Array änderst, wie bei der Methode in Codeblock 3-4 verwendet.

Die Sicherheit und Prägnanz der for-Schleifen machen sie zum am häufigsten verwendeten Schleifenkonstrukt in Rust. Sogar in Situationen, in denen du einen Code bestimmt oft laufen lassen willst, wie im Countdown-Beispiel, das in Codeblock 3-3 eine while-Schleife verwendet hat, würden die meisten Rust-Entwickler eine for-Schleife verwenden. Der Weg, dies zu erreichen, wäre das Verwenden eines Range, der von der Standardbibliothek zur Verfügung gestellt wird und alle Zahlen in Folge generiert, beginnend mit einer Zahl und endend vor einer anderen Zahl.

So würde der Countdown aussehen, wenn man eine for-Schleife und die Methode rev, über die wir noch nicht gesprochen haben und die den Range umkehrt, verwenden würde:

Dateiname: src/main.rs

fn main() {
    for number in (1..4).rev() {
        println!("{number}!");
    }
    println!("ABHEBEN!!!");
}

Dieser Code ist ein bisschen schöner, nicht wahr?

Zusammenfassung

Du hast es geschafft! Das war ein beachtliches Kapitel: Du lerntest etwas über Variablen, Skalare und zusammengesetzte Datentypen, Funktionen, Kommentare, if-Ausdrücke und Schleifen! Um mit den in diesem Kapitel besprochenen Konzepten zu üben, versuche, Programme zu bauen, um Folgendes zu tun:

• Temperaturen zwischen Fahrenheit und Celsius umrechnen.
• Die n-te Fibonacci-Zahl berechnen.
• Den Text des Weihnachtsliedes „Die Zwölf Weihnachtstage“ (The Twelve Days of Christmas) ausgeben und dabei die Wiederholung im Lied nutzen.

Wenn du bereit bist, weiterzumachen, werden wir in Rust über ein Konzept sprechen, das es in anderen Programmiersprachen üblicherweise nicht gibt: Eigentümerschaft (ownership).

Eigentümerschaft (ownership) verstehen

Eigentümerschaft (ownership) ist das wichtigste Alleinstellungsmerkmal von Rust und hat tiefgreifende Auswirkungen auf den Rest der Sprache. Sie ermöglicht es Rust, Speichersicherheitsgarantien ohne Einsatz einer automatischen Speicherbereinigung (garbage collector) zu geben, deshalb ist es wichtig zu verstehen, wie Eigentümerschaft in Rust funktioniert. In diesem Kapitel werden wir uns neben der Eigentümerschaft weitere diesbezügliche Funktionalitäten ansehen: Ausleihen (borrowing), Anteilstypen (slices) und wie Rust Daten im Speicher anordnet.

Was ist Eigentümerschaft (ownership)?

Eigentümerschaft ist eine Reihe von Regeln, die bestimmen, wie ein Rust-Programm den Speicher verwaltet. Alle Programme müssen den Arbeitsspeicher eines Rechners verwalten, während sie ausgeführt werden. Einige Sprachen verfügen über eine automatische Speicherbereinigung, die während der Programmausführung ständig nach nicht mehr genutztem Speicher sucht. Bei anderen Sprachen muss der Programmierer selbst den Speicher explizit reservieren und freigeben. Rust verwendet einen dritten Ansatz: Der Speicher wird durch ein System aus Eigentümerschaft und einer Reihe von Regeln verwaltet, die der Compiler überprüft. Wenn eine der Regeln verletzt wird, lässt sich das Programm nicht kompilieren. Keine der Eigentümerschaftsfunktionalitäten verlangsamt dein Programm, während es läuft.

Da die Eigentümerschaft für viele Programmierer ein neues Konzept ist, braucht es etwas Zeit, sich daran zu gewöhnen. Die gute Nachricht ist, je mehr Erfahrung du mit Rust und den Regeln der Eigentümerschaft gesammelt hast, desto einfacher findest du es, auf natürliche Weise Code zu entwickeln, der sicher und effizient ist. Bleib dran!

Wenn du Eigentümerschaft verstehst, hast du eine solide Grundlage, um die Funktionalitäten zu verstehen, die Rust einzigartig machen. In diesem Kapitel lernst du Eigentümerschaft kennen, indem du einige Beispiele durcharbeitest, die sich auf eine sehr verbreitete Datenstruktur konzentrieren: Zeichenketten (strings).

Stapelspeicher (stack) und Haldenspeicher (heap)

Viele Programmiersprachen erfordern nicht, dass du sehr oft über Stapelspeicher und Haldenspeicher nachdenken musst. Aber in einer Systemprogrammiersprache wie Rust hat die Frage, ob ein Wert auf dem Stapelspeicher oder im Haldenspeicher liegt, einen größeren Einfluss darauf, wie sich die Sprache verhält und warum du bestimmte Entscheidungen treffen musst. Teile der Eigentümerschaft werden später in diesem Kapitel in Bezug auf den Stapelspeicher und den Haldenspeicher beschrieben, daher hier eine kurze Erklärung zur Vorbereitung.

Sowohl Stapelspeicher als auch Haldenspeicher sind Teile des Arbeitsspeichers, die deinem Code zur Laufzeit zur Verfügung stehen, aber sie sind unterschiedlich strukturiert. Der Stapelspeicher speichert Werte in der Reihenfolge, in der er sie erhält, und entfernt die Werte in umgekehrter Reihenfolge. Dies wird als zuletzt herein, zuerst hinaus (last in, first out) bezeichnet. Denke an einen Stapel Teller: Wenn du weitere Teller hinzufügst, legst du sie auf den Stapel, und wenn du einen Teller benötigst, nimmst du einen von oben. Das Hinzufügen oder Entfernen von Tellern aus der Mitte oder von unten würde nicht so gut funktionieren! Das Hinzufügen von Daten nennt man auf den Stapel legen, und das Entfernen von Daten nennt man vom Stapel nehmen. Alle im Stapelspeicher gespeicherten Daten müssen eine bekannte, feste Größe haben. Daten mit einer zur Kompilierzeit unbekannten Größe oder einer Größe, die sich ändern könnte, müssen stattdessen im Haldenspeicher gespeichert werden.

Der Haldenspeicher ist weniger organisiert: Wenn du Daten in den Haldenspeicher legst, forderst du eine bestimmte Menge an Speicherplatz an. Der Speicher-Allokator (memory allocator) sucht eine leere Stelle im Haldenspeicher, die groß genug ist, markiert sie als in Benutzung und gibt einen Zeiger (pointer) zurück, der die Adresse dieser Stelle ist. Dieser Vorgang wird als Allokieren im Haldenspeicher bezeichnet und manchmal mit Allokieren abgekürzt (Das Legen von Werten auf den Stapelspeicher gilt nicht als Allokieren). Da es sich beim Zeiger um eine bekannte, feste Größe handelt, kannst du den Zeiger auf den Stapelspeicher legen, aber wenn du die eigentlichen Daten benötigst, musst du dem Zeiger folgen. Stell dir vor, du sitzt in einem Restaurant. Wenn du hineingehst, gibst du die Anzahl der Personen deiner Gruppe an, und das Personal findet einen leeren Tisch, der groß genug ist, und führt euch dorthin. Wenn jemand aus deiner Gruppe zu spät kommt, kann er fragen, wo ihr Platz genommen habt, um euch zu finden.

Das Legen auf den Stapelspeicher ist schneller als das Allokieren im Haldenspeicher, da der Speicher-Allokator nie nach Platz zum Speichern neuer Daten suchen muss; dieser Ort ist immer ganz oben auf dem Stapel. Im Vergleich dazu erfordert das Allokieren von Speicherplatz im dynamischen Speicher mehr Arbeit, da der Speicher-Allokator zunächst einen ausreichend großen Platz für die Daten finden und dann Buch führen muss, um die nächste Allokation vorzubereiten.

Der Zugriff auf Daten im Haldenspeicher ist langsamer als der Zugriff auf Daten auf dem Stapelspeicher, da du einem Zeiger folgen musst, um dorthin zu gelangen. Heutige Prozessoren sind schneller, wenn sie weniger im Speicher herumspringen. Um die Analogie fortzusetzen, betrachte einen Kellner in einem Restaurant, der an vielen Tischen Bestellungen aufnimmt. Es ist am effizientesten, alle Bestellungen an einem Tisch aufzunehmen, bevor man zum nächsten Tisch weitergeht. Eine Bestellung von Tisch A, dann eine Bestellung von Tisch B, dann wieder eine von A und dann wieder eine von B aufzunehmen, wäre ein viel langsamerer Vorgang. Umgekehrt kann ein Prozessor seine Arbeit besser erledigen, wenn er mit Daten arbeitet, die nahe beieinander liegen (wie sie auf dem Stapelspeicher liegen) und nicht weiter voneinander entfernt (wie sie im Haldenspeicher liegen können). Das Allokieren einer großen Menge an Platz im Haldenspeicher kann ebenfalls Zeit in Anspruch nehmen.

Wenn dein Code eine Funktion aufruft, werden die an die Funktion übergebenen Werte (einschließlich potentieller Zeiger auf Daten im Haldenspeicher) und die lokalen Variablen der Funktion auf den Stapelspeicher gelegt. Wenn die Funktion beendet ist, werden diese Werte vom Stapelspeicher genommen.

Das Nachverfolgen, welche Codeteile welche Daten im Haldenspeicher verwenden, das Minimieren der Menge an doppelten Daten im Haldenspeicher und das Aufräumen ungenutzter Daten im Haldenspeicher, damit dir der Speicherplatz nicht ausgeht, sind alles Probleme, die durch Eigentümerschaft gelöst werden. Wenn du Eigentümerschaft einmal verstanden hast, brauchst du nicht mehr so oft über Stapelspeicher und Haldenspeicher nachzudenken. Aber zu wissen, dass der Hauptzweck der Eigentümerschaft die Verwaltung der Haldenspeicher-Daten ist, kann helfen zu erklären, warum es so funktioniert, wie es funktioniert.

Eigentumsregeln

Lass uns zunächst einen Blick auf die Eigentumsregeln (ownership rules) werfen. Behalte diese Regeln im Hinterkopf, während wir veranschaulichende Beispiele durcharbeiten:

• Jeder Wert in Rust hat einen Eigentümer (owner).
• Es kann immer nur einen Eigentümer zur gleichen Zeit geben.
• Wenn der Eigentümer den Gültigkeitsbereich verlässt, wird der Wert aufgeräumt.

Gültigkeitsbereich (scope) einer Variable

Da wir nun über die grundlegende Syntax hinausgehen, werden wir nicht mehr den gesamten fn main() {-Code in die Beispiele aufnehmen. Wenn du also weitermachst, musst du die folgenden Beispiele manuell in eine Funktion main einfügen. Folglich werden unsere Beispiele etwas prägnanter sein, damit wir uns auf die eigentlichen Details konzentrieren können, anstatt auch den Code darum herum betrachten zu müssen.

Als erstes Beispiel zu Eigentümerschaft werden wir uns den Gültigkeitsbereich (scope) einiger Variablen ansehen. Der Gültigkeitsbereich ist der Bereich innerhalb eines Programms, in dem ein Element gültig ist. Sieh dir folgende Variable an:

#![allow(unused)]
fn main() {
let s = "Hallo";
}

Die Variable s bezieht sich auf ein Zeichenkettenliteral, wobei der Wert der Zeichenkette fest in den Text unseres Programms kodiert ist. Die Variable ist ab der Stelle, an der sie deklariert wurde, bis zum Ende des aktuellen Gültigkeitsbereichs gültig. Codeblock 4-1 zeigt ein Programm mit Kommentaren, die zeigen wo die Variable s gültig ist.

#![allow(unused)]
fn main() {
{                      // s ist hier nicht gültig, es wurde noch nicht deklariert
    let s = "Hallo";   // s ist ab dieser Stelle gültig

    // etwas mit s machen
}                      // dieser Gültigkeitsbereich ist nun vorbei,
                       // und s ist nicht mehr gültig
}

Codeblock 4-1: Eine Variable und der Bereich, in dem sie gültig ist

Mit anderen Worten, es gibt hier zwei wichtige Zeitpunkte:

• Wenn s in den Gültigkeitsbereich kommt, ist es gültig.
• Es bleibt gültig, bis es den Gültigkeitsbereich verlässt.

An diesem Punkt ist die Beziehung zwischen Gültigkeitsbereichen und wann Variablen gültig sind ähnlich zu anderen Programmiersprachen. Nun werden wir auf diesem Verständnis aufbauen, indem wir den Typ String einführen.

Der Typ String

Um die Eigentumsregeln zu veranschaulichen, benötigen wir einen Datentyp, der komplexer ist als die, die wir im Abschnitt „Datentypen“ in Kapitel 3 behandelt haben. Die zuvor behandelten Typen haben eine bekannte Größe, können auf dem Stapelspeicher gelegt und vom Stapelspeicher entfernt werden, wenn ihr Gültigkeitsbereich beendet ist, und können schnell und trivial kopiert werden, um eine neue, unabhängige Instanz zu erzeugen, wenn ein anderer Teil des Codes denselben Wert in einem anderen Gültigkeitsbereich verwenden muss. Wir wollen uns jedoch Daten ansehen, die im Haldenspeicher gespeichert sind, und untersuchen, woher Rust weiß, wann es diese Daten aufräumen muss, und der Typ String ist ein gutes Beispiel dafür.

Wir werden uns auf die Teile von String konzentrieren, die sich auf die Eigentümerschaft beziehen. Diese Aspekte gelten auch für andere komplexe Datentypen, unabhängig davon, ob sie von der Standardbibliothek bereitgestellt oder von dir erstellt wurden. Wir werden String in Kapitel 8 eingehender behandeln.

Wir haben bereits Zeichenkettenliterale gesehen, bei denen ein Zeichenkettenwert fest in unserem Programm kodiert ist. Zeichenkettenliterale sind praktisch, aber sie eignen sich nicht für jede Situation, in der wir Text verwenden möchten. Ein Grund dafür ist, dass sie unveränderbar sind. Ein anderer Grund ist, dass nicht jeder Zeichenkettenwert bekannt ist, wenn wir unseren Code schreiben: Was ist zum Beispiel, wenn wir Benutzereingaben entgegennehmen und speichern wollen? Für diese Situationen hat Rust einen zweiten Zeichenkettentyp: String. Dieser Typ verwaltet Daten, die auf dem Haldenspeicher allokiert sind, und kann so eine Textmenge speichern, die uns zur Kompilierzeit unbekannt ist. Du kannst einen String aus einem Zeichenkettenliteral erzeugen, indem du die Funktion from wie folgt verwendest:

#![allow(unused)]
fn main() {
let s = String::from("Hallo");
}

Der doppelte Doppelpunkt (::) Operator erlaubt uns, diese spezielle Funktion from mit dem Namensraum des String-Typs zu benennen, anstatt einen Namen wie string_from zu verwenden. Wir werden diese Syntax im Abschnitt „Methodensyntax“ in Kapitel 5 näher betrachten, und wenn wir in Kapitel 7 unter „Mit Pfaden auf ein Element im Modulbaum verweisen“ über den Namensraum mit Modulen sprechen.

Diese Art von Zeichenkette kann verändert werden:

#![allow(unused)]
fn main() {
let mut s = String::from("Hallo");

s.push_str(" Welt!"); // push_str() hängt ein Literal an eine Zeichenfolge an

println!("{}", s);    // Gibt `Hallo Welt!` aus
}

Was ist hier nun der Unterschied? Warum kann String verändert werden, Literale jedoch nicht? Der Unterschied liegt darin, wie diese beiden Typen mit dem Arbeitsspeicher umgehen.

Speicher und Allokation

Im Falle eines Zeichenkettenliterals kennen wir den Inhalt zum Zeitpunkt der Kompilierung, sodass der Text direkt in die endgültige ausführbare Datei fest kodiert wird. Aus diesem Grund sind Zeichenkettenliterale schnell und effizient. Allerdings ergeben sich diese Eigenschaften nur aus der Unveränderbarkeit des Zeichenkettenliterals. Leider können wir nicht für jedes Stück Text, dessen Größe zum Zeitpunkt der Kompilierung unbekannt ist und dessen Größe sich während der Ausführung des Programms ändern könnte, einen Speicherblock in die Binärdatei packen.

Um mit dem Typ String einen veränderbaren, größenänderbaren Textabschnitt zu unterstützen, müssen wir Speicher im Haldenspeicher allokieren, dessen Größe zur Kompilierzeit unbekannt ist. Dies bedeutet:

• Der Speicher muss zur Laufzeit vom Speicher-Allokator angefordert werden.
• Wir brauchen eine Möglichkeit, diesen Speicher an den Speicher-Allokator zurückzugeben, wenn wir mit unserem String fertig sind.

Der erste Teil wird von uns erledigt: Wenn wir String::from aufrufen, fordert seine Implementierung den Speicher an, den sie benötigt. Dies ist in Programmiersprachen ziemlich einheitlich.

Der zweite Teil ist jedoch anders. In Sprachen mit einer automatischen Speicherbereinigung (garbage collector, GC) behält der GC den Überblick und räumt Speicherplatz, der nicht mehr verwendet wird, auf; wir brauchen nicht darüber nachzudenken. Ohne einen GC liegt es in unserer Verantwortung, zu erkennen, wann Speicherplatz nicht mehr benutzt wird, und Code aufzurufen, der ihn explizit zurückgibt, so wie wir es beim Anfordern auch getan haben. Dies korrekt zu tun, war in der Vergangenheit ein schwieriges Programmierproblem. Wenn wir es vergessen, verschwenden wir Speicher. Wenn wir es zu früh machen, haben wir eine ungültige Variable. Wenn wir es zweimal machen, ist das auch ein Fehler. Wir müssen eine Allokierung mit genau einer Freigabe paaren.

Rust geht einen anderen Weg: Der Speicher wird automatisch zurückgegeben, sobald die Variable, die ihn besitzt, den Gültigkeitsbereich verlässt. Hier ist eine Variante unseres Gültigkeitsbereich-Beispiels aus Codeblock 4-1, bei der ein String anstelle eines Zeichenkettenliterals verwendet wird:

#![allow(unused)]
fn main() {
{
    let s = String::from("Hallo"); // s ist ab dieser Stelle gültig

    // etwas mit s machen
}                                  // dieser Gültigkeitsbereich ist nun vorbei,
                                   // und s ist nicht mehr gültig
}

Es gibt eine natürliche Stelle, an der wir den Speicher, den unser String benötigt, an den Speicher-Allokator zurückgeben können: Wenn s den Gültigkeitsbereich verlässt. Wenn eine Variable den Gültigkeitsbereich verlässt, ruft Rust für uns eine spezielle Funktion auf: Diese Funktion heißt drop und an dieser Stelle kann der Autor von String Code einfügen, um den Speicher zurückzugeben. Rust ruft drop automatisch an der schließenden geschweiften Klammer auf.

Hinweis: In C++ wird dieses Muster der Freigabe von Ressourcen am Ende der Lebensdauer eines Elements manchmal als Ressourcenbelegung ist Initialisierung (resource acquisition is initialization, RAII) bezeichnet. Die Funktion drop in Rust wird dir vertraut vorkommen, wenn du bereits RAII-Muster verwendet hast.

Dieses Muster hat einen tiefgreifenden Einfluss auf die Art und Weise, wie Rust-Code geschrieben wird. Es mag im Moment einfach erscheinen, aber das Verhalten von Code kann in komplizierteren Situationen unerwartet sein, wenn wir wollen, dass mehrere Variablen Daten verwenden, die wir im dynamischen Speicher allokiert haben. Lass uns jetzt einige dieser Situationen untersuchen.

Variablen und Daten im Zusammenspiel mit Move

Mehrere Variablen können in Rust auf unterschiedliche Weise mit denselben Daten interagieren. Betrachten wir ein Beispiel mit einer ganzen Zahl in Codeblock 4-2.

#![allow(unused)]
fn main() {
let x = 5;
let y = x;
}

Codeblock 4-2: Zuweisen des ganzzahligen Wertes der Variablen x an y

Wir können wahrscheinlich erahnen, was das bewirkt: „Binde den Wert 5 an x; dann erstelle eine Kopie des Wertes in x und binde ihn an y.“ Wir haben jetzt zwei Variablen x und y und beide sind gleich 5. Das ist in der Tat der Fall, denn ganze Zahlen sind einfache Werte mit einer bekannten, festen Größe, und diese beiden Werte 5 werden auf den Stapelspeicher gelegt.

Schauen wir uns nun die String-Variante an:

#![allow(unused)]
fn main() {
let s1 = String::from("Hallo");
let s2 = s1;
}

Dies sieht sehr ähnlich aus, sodass wir annehmen könnten, dass die Funktionsweise die gleiche wäre: Das heißt, die zweite Zeile würde eine Kopie des Wertes in s1 erstellen und sie an s2 binden. Aber das ist nicht ganz das, was passiert.

Betrachte Abbildung 4-1, um zu sehen, was mit dem String unter der Haube geschieht. Ein String besteht aus drei Teilen, die auf der linken Seite dargestellt sind: Einem Zeiger auf den Speicherbereich, der den Inhalt der Zeichenkette enthält, die Länge und die Kapazität. Dieser Datenblock wird auf dem Stapelspeicher gespeichert. Auf der rechten Seite ist der Speicherbereich im Haldenspeicher, der den Inhalt enthält.

Abbildung 4-1: Speicherdarstellung eines String mit dem Wert „Hallo“, gebunden an s1

Die Länge gibt an, wie viel Speicherplatz in Bytes der Inhalt der Zeichenkette derzeit belegt. Die Kapazität ist die Gesamtmenge des Speichers in Bytes, die der String vom Speicher-Allokator erhalten hat. Der Unterschied zwischen Länge und Kapazität ist von Bedeutung, aber nicht in diesem Zusammenhang, deshalb ist es im Moment in Ordnung, die Kapazität zu ignorieren.

Wenn wir s1 an s2 zuweisen, werden die String-Daten kopiert, d.h. wir kopieren den Zeiger, die Länge und die Kapazität, die sich auf dem Stapelspeicher befinden. Wir kopieren nicht die Daten im Haldenspeicher, auf die sich der Zeiger bezieht. Die Speicherdarstellung sieht also wie in Abbildung 4-2 aus.

Abbildung 4-2: Speicherdarstellung der Variable s2, die eine Kopie des Zeigers, der Länge und der Kapazität von s1 hat

Die Darstellung sieht nicht wie Abbildung 4-3 aus, so wie der Speicher aussehen würde, wenn Rust stattdessen auch die Daten im Haldenspeicher kopieren würde. Würde Rust dies tun, könnte die Operation s2 = s1 bei großen Datenmengen im Haldenspeicher sehr teuer hinsichtlich der Laufzeitperformanz werden.

Abbildung 4-3: Eine weitere Möglichkeit für das, was s2 = s1 tun könnte, falls Rust auch die Daten im Haldenspeicher kopieren würde

Vorhin sagten wir, dass Rust automatisch die Funktion drop aufruft und den Haldenspeicher für diese Variable säubert, wenn eine Variable den Gültigkeitsbereich verlässt. Abbildung 4-2 zeigt jedoch, dass beide Datenzeiger auf dieselbe Stelle zeigen. Das ist ein Problem: Wenn s2 und s1 den Gültigkeitsbereich verlassen, werden beide versuchen, den gleichen Speicher freizugeben. Dies wird als doppelter Freigabefehler (double free error) bezeichnet und ist einer der Speichersicherheitsfehler, die wir zuvor erwähnt haben. Das zweimalige Freigeben des Speichers kann zu einer Speicherverfälschung führen, was potenziell zu Sicherheitslücken führen kann.

Um Speichersicherheit zu gewährleisten, betrachtet Rust nach der Zeile let s2 = s1; die Variable s1 als nicht mehr gültig. Daher braucht Rust nichts freizugeben, wenn s1 den Gültigkeitsbereich verlässt. Schau dir an, was passiert, wenn du versuchst, s1 zu benutzen, nachdem s2 erstellt wurde; es wird nicht funktionieren:

#![allow(unused)]
fn main() {
let s1 = String::from("Hallo");
let s2 = s1;

println!("{} Welt!", s1);
}

Du erhältst eine Fehlermeldung wie diese, wodurch Rust dich daran hindert, die ungültige Referenz zu verwenden:

$ cargo run
   Compiling ownership v0.1.0 (file:///projects/ownership)
error[E0382]: borrow of moved value: `s1`
 --> src/main.rs:5:28
  |
2 |     let s1 = String::from("Hallo");
  |         -- move occurs because `s1` has type `String`, which does not implement the `Copy` trait
3 |     let s2 = s1;
  |              -- value moved here
4 |
5 |     println!("{} Welt!", s1);
  |                          ^^ value borrowed here after move
  |
  = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value if the performance cost is acceptable
  |
3 |     let s2 = s1.clone();
  |                ++++++++

For more information about this error, try `rustc --explain E0382`.
error: could not compile `ownership` (bin "ownership") due to 1 previous error

Wenn du beim Arbeiten mit anderen Sprachen schon mal die Begriffe flache Kopie (shallow copy) und tiefe Kopie (deep copy) gehört hast, hört sich das Konzept des Kopierens des Zeigers, der Länge und der Kapazität ohne Kopieren der Daten nach einer flachen Kopie an. Aber weil Rust auch die erste Variable ungültig macht, wird es nicht als flache Kopie, sondern als Verschieben (move) bezeichnet. In diesem Beispiel würden wir sagen, dass s1 in s2 verschoben wurde. Was tatsächlich geschieht, ist in Abbildung 4-4 dargestellt.

Abbildung 4-4: Speicherdarstellung, nachdem s1 ungültig gemacht wurde

Damit ist unser Problem gelöst! Da nur s2 gültig ist, wenn es den Gültigkeitsbereich verlässt, wird es allein den Speicher freigeben, und wir sind fertig.

Darüber hinaus gibt es eine Entwurfsentscheidung, die damit impliziert ist: Rust wird niemals automatisch „tiefe“ Kopien deiner Daten erstellen. Daher kann man davon ausgehen, dass jedes automatische Kopieren im Hinblick auf die Laufzeitperformanz kostengünstig ist.

Variablen und Daten im Zusammenspiel mit Clone

Wenn wir die Daten von String im Haldenspeicher tief kopieren wollen, nicht nur die Stapelspeicher-Daten, können wir eine gängige Methode namens clone verwenden. Wir werden die Methodensyntax in Kapitel 5 besprechen, aber da Methoden eine gängige Funktionalität vieler Programmiersprachen sind, hast du sie wahrscheinlich schon einmal gesehen.

Hier ist ein Beispiel für die Methode clone:

#![allow(unused)]
fn main() {
let s1 = String::from("Hallo");
let s2 = s1.clone();

println!("s1 = {}, s2 = {}", s1, s2);
}

Das funktioniert sehr gut und erzeugt explizit das in Abbildung 4-3 gezeigte Verhalten, bei dem die Daten im Haldenspeicher kopiert werden.

Wenn du einen Aufruf von clone siehst, weißt du, dass irgendein beliebiger Code ausgeführt wird und dass dieser Code teuer sein könnte. Es ist ein visueller Indikator dafür, dass etwas anderes vor sich geht.

Nur Stapelspeicher-Daten: Kopieren (copy)

Es gibt noch einen weiteren Kniff, über den wir noch nicht gesprochen haben. Folgender Code mit ganzen Zahlen, der teilweise in Codeblock 4-2 gezeigt wurde, funktioniert und ist gültig:

#![allow(unused)]
fn main() {
let x = 5;
let y = x;

println!("x = {}, y = {}", x, y);
}

Aber dieser Code scheint dem zu widersprechen, was wir gerade gelernt haben: Wir haben keinen Aufruf von clone, aber x ist immer noch gültig und wurde nicht in y verschoben.

Der Grund dafür ist, dass Typen wie ganze Zahlen, die zur Kompilierzeit eine bekannte Größe haben, vollständig auf dem Stack gespeichert werden, so dass Kopien der tatsächlichen Werte schnell erstellt werden können. Das bedeutet, dass es keinen Grund gibt, warum wir verhindern wollen, dass x gültig ist, nachdem wir die Variable y erstellt haben. Mit anderen Worten, es gibt hier keinen Unterschied zwischen tiefen und flachen Kopien, also würde der Aufruf clone nichts anderes tun als das übliche flache Kopieren, und wir können es weglassen.

Rust hat eine spezielle Annotation, das Merkmal Copy, die wir an Typen hängen können, die auf dem Stapelspeicher wie ganze Zahlen gespeichert sind (wir werden in Kapitel 10 mehr über Merkmale sprechen). Wenn ein Typ das Merkmal Copy implementiert, werden Variablen, die dieses Merkmal verwenden, nicht verschoben, sondern trivialerweise kopiert, sodass sie auch nach der Zuweisung an eine andere Variable noch gültig sind.

Rust lässt uns einen Typ nicht mit dem Merkmal Copy annotieren, wenn der Typ oder einer seiner Teile das Merkmal Drop implementiert. Wenn der Typ eine Sonderbehandlung benötigt, wenn der Wert den Gültigkeitsbereich verlässt und wir die Annotation Copy zu diesem Typ hinzufügen, erhalten wir einen Kompilierfehler. Um zu erfahren, wie du die Copy-Annotation zu deinem Typ hinzufügen kannst, siehe „Ableitbare Merkmale (traits)“ in Anhang C.

Welche Typen unterstützen also Copy? Du kannst die Dokumentation für einen gegebenen Typ überprüfen, um sicherzugehen, aber als allgemeine Regel gilt: Jede Gruppierung von einfachen skalaren Werten unterstützt Copy, und nichts, was eine Allokation erfordert oder irgendeine Form von Ressource ist, kann Copy implementieren. Hier sind einige Typen, die Copy unterstützen:

• Alle ganzzahligen Typen, z.B. u32.
• Der boolesche Typ bool mit den Werten true und false.
• Alle Fließkomma-Typen, z.B. f64.
• Der Zeichentyp char.
• Tupel, wenn sie nur Typen enthalten, die auch Copy unterstützen. Zum Beispiel unterstützt (i32, i32) Copy, nicht aber (i32, String).

Eigentümerschaft und Funktionen

Die Übergabe eines Wertes an eine Funktion funktioniert ähnlich wie die Zuweisung eines Wertes an eine Variable. Wenn eine Variable an eine Funktion übergeben wird, wird sie verschoben oder kopiert, genau wie bei der Zuweisung. Codeblock 4-3 enthält ein Beispiel mit einigen Anmerkungen, aus denen hervorgeht, wo Variablen in den Gültigkeitsbereich fallen und wo nicht.

Dateiname: src/main.rs

fn main() {
    let s = String::from("Hallo");  // s kommt in den Gültigkeitsbereich

    takes_ownership(s);             // Der Wert von s wird in die Funktion
                                    // verschoben und ist daher hier nicht
                                    // mehr gültig.

    let x = 5;                      // x kommt in den Gültigkeitsbereich

    makes_copy(x);                  // x würde in die Funktion verschoben werden,
                                    // aber i32 erlaubt Copy, also ist es in
                                    // Ordnung, danach immer noch x zu verwenden.

} // Hier verlassen s und x den Gültigkeitsbereich.
  // Aber weil der Wert von s verschoben wurde, passiert nichts Besonderes.

fn takes_ownership(some_string: String) { // some_string kommt in den
                                          // Gültigkeitsbereich
    println!("{}", some_string);
} // Hier verlässt some_string den Gültigkeitsbereich und `drop` wird aufgerufen.
  // Der zugehörige Speicherplatz wird freigegeben.

fn makes_copy(some_integer: i32) { // some_integer kommt in den Gültigkeitsbereich
    println!("{}", some_integer);
} // Hier verlässt some_integer den Gültigkeitsbereich.
  // Es passiert nichts Besonderes.

Codeblock 4-3: Funktionen mit kommentierter Eigentümerschaft und Gültigkeitsbereich

Wenn wir versuchen würden, s nach dem Aufruf von takes_ownership zu verwenden, würde Rust einen Kompilierfehler anzeigen. Diese statischen Prüfungen schützen uns vor Fehlern. Versuche, weiteren Code zu main hinzuzufügen, der s und x verwendet, um zu sehen, wo du sie verwenden kannst und wo die Eigentumsregeln dich daran hindern.

Rückgabewerte und Gültigkeitsbereich

Rückgabewerte können auch Eigentümerschaft übertragen. Codeblock 4-4 ist ein Beispiel für eine Funktion mit einem Rückgabewert mit ähnlichen Anmerkungen wie die in Codeblock 4-3.

Dateiname: src/main.rs

fn main() {
    let s1 = gives_ownership();         // gives_ownership verschiebt seinen
                                        // Rückgabewert in s1

    let s2 = String::from("Hallo");     // s2 kommt in den Gültigkeitsbereich

    let s3 = takes_and_gives_back(s2);  // s2 wird in takes_and_gives_back
                                        // verschoben und der Rückgabewert
                                        // wird in s3 verschoben

} // Hier verlässt s3 den Gültigkeitsbereich und wird aufgeräumt.
  // s2 wurde verschoben, es passiert also nichts.
  // s1 verlässt den Gültigkeitsbereich und wird aufgeräumt.

fn gives_ownership() -> String {        // gives_ownership verschiebt seinen
                                        // Rückgabewert in die aufrufende Funktion

    let some_string = String::from("Hallo"); // some_string kommt in den
                                             // Gültigkeitsbereich

    some_string                         // some_string wird zurückgegeben und
                                        // wird an die aufrufende Funktion
                                        // verschoben
}

// Diese Funktion nimmt einen String entgegen und gibt einen zurück
fn takes_and_gives_back(a_string: String) -> String { // a_string kommt in den
                                                      // Gültigkeitsbereich

    a_string  // a_string wird zurückgegeben und
              // an die aufrufende Funktion verschoben
}

Codeblock 4-4: Übertragen der Eigentümerschaft an Rückgabewerten

Die Eigentümerschaft an einer Variable folgt jedes Mal dem gleichen Muster: Das Zuweisen eines Wertes an eine andere Variable verschiebt diese. Wenn eine Variable, die Daten im Haldenspeicher enthält, den Gültigkeitsbereich verlässt, wird der Wert durch drop aufgeräumt, es sei denn, die Eigentümerschaft wurde auf eine andere Variable verschoben.

Dies funktioniert zwar, allerdings ist es etwas mühsam, die Eigentümerschaft zu übernehmen und in jeder Funktion zurückzugeben. Was ist, wenn wir eine Funktion einen Wert nutzen lassen wollen, aber nicht die Eigentümerschaft übergeben wollen? Es ist ziemlich lästig, dass alles, was wir übergeben, auch wieder zurückgegeben werden muss, wenn wir es wieder verwenden wollen, zusätzlich zu den Daten, die sich aus dem Funktionsrumpf ergeben, die wir vielleicht auch zurückgeben wollen.

Rust macht es es möglich, mehrere Werte mit Hilfe eines Tupels zurückzugeben, wie in Codeblock 4-5 gezeigt.

Dateiname: src/main.rs

fn main() {
    let s1 = String::from("Hallo");

    let (s2, len) = calculate_length(s1);

    println!("Die Länge von '{}' ist {}.", s2, len);
}

fn calculate_length(s: String) -> (String, usize) {
    let length = s.len(); // len() gibt die Länge der Zeichenkette zurück

    (s, length)
}

Codeblock 4-5: Rückgeben der Eigentümerschaft an Parametern

Aber das ist zu viel Zeremonie und zu viel Arbeit für ein Konzept, das gebräuchlich sein sollte. Zum Glück gibt es in Rust eine Funktion, mit der man einen Wert verwenden kann, ohne die Eigentümerschaft zu übertragen, nämlich Referenzen (references).

Referenzen und Ausleihen (borrowing)

Das Problem mit dem Tupelcode in Codeblock 4-5 ist, dass wir der aufrufenden Funktion den String zurückgeben müssen, damit wir den String nach dem Aufruf von calculate_length weiter verwenden können, weil der String in calculate_length verschoben wurde. Stattdessen können wir eine Referenz auf den String-Wert angeben. Eine Referenz ist wie ein Zeiger, d.h. eine Adresse, der wir folgen können, um auf Daten zugreifen zu können, die an dieser Adresse gespeichert sind und einer anderen Variablen gehören. Im Gegensatz zu einem Zeiger ist bei einer Referenz garantiert, dass sie auf einen gültigen Wert eines bestimmten Typs zeigt.

Im Folgenden siehst du, wie du eine Funktion calculate_length definieren und verwenden kannst, die eine Referenz auf ein Objekt als Parameter hat, anstatt die Eigentümerschaft (ownership) des Wertes zu übernehmen:

Dateiname: src/main.rs

fn main() {
    let s1 = String::from("Hallo");

    let len = calculate_length(&s1);

    println!("Die Länge von '{}' ist {}.", s1, len);
}

fn calculate_length(s: &String) -> usize {
    s.len()
}

Beachte, dass der gesamte Tupelcode aus der Variablendeklaration und dem Rückgabewert der Funktion verschwunden ist. Beachte des Weiteren, dass wir &s1 an calculate_length übergeben und in seiner Definition &String statt String steht. Das &-Zeichen steht für eine Referenz, und sie ermöglicht es dir, sich auf einen Wert zu beziehen, ohne dessen Eigentümerschaft zu übernehmen. Abbildung 4-5 zeigt die Speicherdarstellung.

Abbildung 4-5: Eine Grafik mit &String s, das auf String s1 zeigt

Anmerkung: Das Gegenteil der Referenzierung durch & ist die Dereferenzierung (dereferencing), die mittels Dereferenzoperator * erfolgt. Wir werden in Kapitel 8 einige Verwendungen des Dereferenzoperators sehen und in Kapitel 15 Einzelheiten der Dereferenzierung besprechen.

Schauen wir uns den Funktionsaufruf hier genauer an:

fn main() {
    let s1 = String::from("Hallo");

    let len = calculate_length(&s1);

    println!("Die Länge von '{}' ist {}.", s1, len);
}

fn calculate_length(s: &String) -> usize {
    s.len()
}

Die Syntax &s1 erlaubt es uns, eine Referenz zu erstellen, die auf den Wert von s1 referenziert, ihn aber nicht besitzt. Da sie diesen nicht besitzt, verfällt der Wert, auf den sie verweist, nicht, wenn die Referenz nicht mehr benutzt wird.

Ebenso verwendet die Signatur der Funktion das Zeichen &, um anzuzeigen, dass der Typ des Parameters s eine Referenz ist. Lass uns einige erklärende Anmerkungen ergänzen:

fn main() {
    let s1 = String::from("Hallo");

    let len = calculate_length(&s1);

    println!("Die Länge von '{}' ist {}.", s1, len);
}

fn calculate_length(s: &String) -> usize { // s ist eine Referenz
                                           // auf eine Zeichenkette
    s.len()
} // Hier verlässt s den Gültigkeitsbereich. Aber weil es keine
  // Eigentümerschaft an dem hat, worauf es referenziert, passiert nichts.

Der Gültigkeitsbereich, in dem die Variable s gültig ist, ist derselbe wie der Gültigkeitsbereich eines Funktionsparameters, aber der Wert, auf den die Referenz zeigt, wird nicht aufgeräumt, wenn s nicht mehr verwendet wird, weil s keine Eigentümerschaft hat. Wenn Funktionen statt der tatsächlichen Werte Referenzen als Parameter haben, brauchen wir die Werte nicht zurückzugeben, um die Eigentümerschaft zurückzugeben, denn wir hatten nie die Eigentümerschaft.

Wir nennen den Vorgang des Erstellens einer Referenz Ausleihen (borrowing). Wenn eine Person im richtigen Leben etwas besitzt, kannst du es von ihr ausleihen. Wenn du fertig bist, musst du es zurückgeben. Es gehört dir nicht.

Was passiert nun, wenn wir versuchen, etwas zu verändern, das wir uns ausleihen? Versuche den Code in Codeblock 4-6. Achtung: Es funktioniert nicht!

Dateiname: src/main.rs

fn main() {
    let s = String::from("Hallo");

    change(&s);
}

fn change(some_string: &String) {
    some_string.push_str(" Welt");
}

Codeblock 4-6: Versuch, einen ausgeliehenen Wert zu verändern

Hier ist die Fehlermeldung:

$ cargo run
   Compiling ownership v0.1.0 (file:///projects/ownership)
error[E0596]: cannot borrow `*some_string` as mutable, as it is behind a `&` reference
 --> src/main.rs:8:5
  |
8 |     some_string.push_str(" Welt");
  |     ^^^^^^^^^^^ `some_string` is a `&` reference, so the data it refers to cannot be borrowed as mutable
  |
help: consider changing this to be a mutable reference
  |
7 | fn change(some_string: &mut String) {
  |                         +++

For more information about this error, try `rustc --explain E0596`.
error: could not compile `ownership` (bin "ownership") due to 1 previous error

So wie Variablen standardmäßig unveränderbar sind, so sind auch Referenzen unveränderbar. Es ist uns nicht erlaubt, etwas zu verändern, auf das wir eine Referenz haben.

Veränderbare Referenzen

Wir können den Code aus Codeblock 4-6 so ändern, dass wir einen geliehenen Wert mit ein paar kleinen Änderungen ändern können, die stattdessen eine veränderbare Referenz verwenden:

Dateiname: src/main.rs

fn main() {
    let mut s = String::from("Hallo");

    change(&mut s);
}

fn change(some_string: &mut String) {
    some_string.push_str(" Welt");
}

Zuerst ändern wir s, um mut zu sein. Dann erstellen wir eine veränderbare Referenz mit &mut s, wo wir die Funktion change aufrufen, und aktualisieren die Funktionssignatur, um eine veränderbare Referenz mit some_string: &mut String entgegenzunehmen. Dies macht deutlich, dass die Funktion change den Wert, den sie ausleiht, verändert.

Veränderbare Referenzen haben eine große Einschränkung: Wenn du eine veränderbare Referenz auf einen Wert hast, kannst du keine andere Referenz auf diesen Wert haben. Dieser Code versucht, zwei veränderbare Referenzen auf s zu erstellen, und wird fehlschlagen:

Dateiname: src/main.rs

#![allow(unused)]
fn main() {
let mut s = String::from("Hallo");

let r1 = &mut s;
let r2 = &mut s;

println!("{}, {}", r1, r2);
}

Hier ist die Fehlermeldung:

$ cargo run
   Compiling ownership v0.1.0 (file:///projects/ownership)
error[E0499]: cannot borrow `s` as mutable more than once at a time
 --> src/main.rs:5:14
  |
4 |     let r1 = &mut s;
  |              ------ first mutable borrow occurs here
5 |     let r2 = &mut s;
  |              ^^^^^^ second mutable borrow occurs here
6 | 
7 |     println!("{}, {}", r1, r2);
  |                        -- first borrow later used here

For more information about this error, try `rustc --explain E0499`.
error: could not compile `ownership` (bin "ownership") due to 1 previous error

Dieser Fehler besagt, dass dieser Code ungültig ist, weil wir s nicht mehr als einmal zur gleichen Zeit als veränderbar ausleihen können. Die erste veränderbare Ausleihe ist in r1 und muss beibehalten werden, bis sie in println! verwendet wird, aber zwischen dem Erstellen dieser veränderbaren Referenz und ihrer Verwendung haben wir versucht, eine andere veränderbare Referenz in r2 zu erstellen, der die gleichen Daten wie r1 ausleiht.

Die Beschränkung, die mehrere veränderbare Referenz auf dieselben Daten zur gleichen Zeit verhindert, erlaubt Veränderung, aber in einer sehr kontrollierten Weise. Das ist etwas, womit Rust-Neulinge zu kämpfen haben, denn in den meisten Sprachen kann man verändern wann immer man will. Diese Beschränkung hat den Vorteil, dass Rust Daten-Wettlaufsituation zur Kompilierzeit verhindern kann. Eine Daten-Wettlaufsituation (data race) ist ähnlich einer Wettlaufsituation (race condition) und tritt auf, wenn diese drei Verhaltensweisen auftreten:

• Zwei oder mehr Zeiger greifen gleichzeitig auf die gleichen Daten zu.
• Mindestens einer der Zeiger wird zum Schreiben auf die Daten verwendet.
• Es gibt keinen Mechanismus, um den Zugriff auf die Daten zu synchronisieren.

Daten-Wettlaufsituationen verursachen undefiniertes Verhalten und können schwierig zu diagnostizieren und zu beheben sein, wenn du versuchst, sie zur Laufzeit aufzuspüren; Rust verhindert dieses Problem, indem es Code mit Daten-Wettlaufsituationen gar nicht erst kompiliert!

Wie immer können wir geschweifte Klammern verwenden, um einen neuen Gültigkeitsbereich zu schaffen, der mehrere veränderbare Referenzen erlaubt, nur nicht gleichzeitige:

#![allow(unused)]
fn main() {
let mut s = String::from("Hallo");

{
    let r1 = &mut s;
} // r1 verlässt hier den Gültigkeitsbereich, sodass wir
  // problemlos eine neue Referenz erstellen können.

let r2 = &mut s;
}

Rust erzwingt eine ähnliche Regel für die Kombination von veränderbaren und unveränderbaren Referenzen. Dieser Code führt zu einem Fehler:

#![allow(unused)]
fn main() {
let mut s = String::from("Hallo");

let r1 = &s;     // kein Problem
let r2 = &s;     // kein Problem
let r3 = &mut s; // GROSSES PROBLEM

println!("{}, {} und {}", r1, r2, r3);
}

Hier ist die Fehlermeldung:

$ cargo run
   Compiling ownership v0.1.0 (file:///projects/ownership)
error[E0502]: cannot borrow `s` as mutable because it is also borrowed as immutable
 --> src/main.rs:6:14
  |
4 |     let r1 = &s;     // kein Problem
  |              -- immutable borrow occurs here
5 |     let r2 = &s;     // kein Problem
6 |     let r3 = &mut s; // GROSSES PROBLEM
  |              ^^^^^^ mutable borrow occurs here
7 | 
8 |     println!("{}, {} und {}", r1, r2, r3);
  |                               -- immutable borrow later used here

For more information about this error, try `rustc --explain E0502`.
error: could not compile `ownership` (bin "ownership") due to 1 previous error

Puh! Wir können auch keine veränderbaren Referenzen verwenden, solange wir eine unveränderbare Referenz auf denselben Wert haben.

Nutzer einer unveränderbaren Referenz erwarten nicht, dass sich die Werte dahinter plötzlich ändern! Mehrere unveränderbare Referenzen sind jedoch in Ordnung, da niemand, der die Daten nur liest, die Möglichkeit hat, das Lesen der Daten durch andere zu beeinflussen.

Beachte, dass der Gültigkeitsbereich einer Referenz dort beginnt, wo sie eingeführt wird, und sich bis zur letzten Verwendung dieser Referenz fortsetzt. Zum Beispiel kompiliert dieser Code, weil die letzte Verwendung der unveränderbaren Referenzen in println! vor der Einführung der veränderbaren Referenz erfolgt:

#![allow(unused)]
fn main() {
let mut s = String::from("Hallo");

let r1 = &s; // kein Problem
let r2 = &s; // kein Problem
println!("{} und {}", r1, r2);
// r1 und r2 werden nach dieser Stelle nicht mehr verwendet

let r3 = &mut s; // kein Problem
println!("{}", r3);
}

Die Gültigkeitsbereiche der unveränderbaren Referenzen r1 und r2 enden nach dem println!, wo sie zuletzt verwendet werden, d.h. bevor die veränderbare Referenz r3 erstellt wird. Diese Gültigkeitsbereiche überschneiden sich nicht, daher ist dieser Code zulässig: Der Compiler kann erkennen, dass die Referenz bereits vor dem Ende des Gültigkeitsbereichs nicht mehr verwendet wird.

Auch wenn Fehler durch Ausleihen manchmal frustrierend sein können, denke daran, dass es der Rust-Compiler ist, der frühzeitig (zur Kompilierzeit und nicht zur Laufzeit) auf einen möglichen Fehler hinweist und dir genau zeigt, wo das Problem liegt. Dann musst du nicht aufspüren, warum deine Daten nicht so sind, wie du dachtest.

Hängende Referenzen

In Sprachen mit Zeigern ist es leicht, fälschlicherweise einen hängenden Zeiger (dangling pointer) zu erzeugen, also einen Zeiger, der auf eine Stelle im Speicher verweist, die vielleicht an jemand anderem vergeben wurde, weil der Speicher freigegeben wurde, während noch ein Zeiger auf diesen Speicher bestehen bleibt. In Rust hingegen garantiert der Compiler, dass Referenzen niemals hängende Referenzen sein können: Wenn du eine Referenz auf Daten hast, stellt der Compiler sicher, dass die Daten nicht den Gültigkeitsbereich verlassen, bevor die Referenz auf die Daten dies tut.

Versuchen wir, eine hängende Referenz zu erstellen, um zu sehen wie Rust das mit einem Kompilierfehler verhindert:

Dateiname: src/main.rs

fn main() {
    let reference_to_nothing = dangle();
}

fn dangle() -> &String {
    let s = String::from("Hallo");

    &s
}

Hier ist die Fehlermeldung:

$ cargo run
   Compiling ownership v0.1.0 (file:///projects/ownership)
error[E0106]: missing lifetime specifier
 --> src/main.rs:5:16
  |
5 | fn dangle() -> &String {
  |                ^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`
  |
5 | fn dangle() -> &'static String {
  |                 +++++++
help: instead, you are more likely to want to return an owned value
  |
5 - fn dangle() -> &String {
5 + fn dangle() -> String {
  |

For more information about this error, try `rustc --explain E0106`.
error: could not compile `ownership` (bin "ownership") due to 1 previous error

Diese Fehlermeldung bezieht sich auf eine Funktionalität, die wir noch nicht behandelt haben: Die Lebensdauer. Wir werden die Lebensdauer in Kapitel 10 im Detail besprechen. Abgesehen von den Hinweisen zur Lebensdauer enthält die Meldung den entscheidenden Hinweis, warum dieser Code nicht funktioniert:

this function's return type contains a borrowed value, but there is no value
for it to be borrowed from

Lass uns einen genaueren Blick auf das werfen, was in jeder Phase unseres dangle-Codes geschieht:

Dateiname: src/main.rs

fn main() {
    let reference_to_nothing = dangle();
}

fn dangle() -> &String { // dangle gibt eine Referenz
                         // auf eine Zeichenkette zurück

    let s = String::from("Hallo"); // s ist eine neue Zeichenkette

    &s // wir geben einen Verweis auf die Zeichenkette s zurück
} // Hier verlässt s den Gültigkeitsbereich und wird verworfen.
  // Sein Speicherplatz wird aufgeräumt. Gefahr!

Da s innerhalb dangle erzeugt wird, wird s wieder freigegeben, wenn der Code von dangle zu Ende ist. Aber wir haben versucht, eine Referenz darauf zurückzugeben. Das heißt, diese Referenz würde auf einen ungültigen String verweisen. Das ist nicht gut! Rust lässt uns das nicht tun.

Die Lösung ist, den String direkt zurückzugeben:

fn main() {
    let string = no_dangle();
}

fn no_dangle() -> String {
    let s = String::from("Hallo");

    s
}

Dies funktioniert ohne Probleme. Die Eigentümerschaft wird nach außen verschoben, und nichts wird freigegeben.

Regeln für Referenzen

Lass uns rekapitulieren, was wir über Referenzen gelernt haben:

• Zu jedem beliebigen Zeitpunkt kannst du entweder eine veränderbare Referenz oder eine beliebige Anzahl unveränderbarer Referenzen haben.
• Referenzen müssen immer gültig sein.

Als Nächstes werden wir uns mit einer anderen Art von Referenz befassen: Anteilstypen (slice).

Der Anteilstyp (slice)

Mit Anteilstypen kannst du auf eine zusammenhängende Folge von Elementen in einer Kollektion referenzieren anstatt auf die gesamte Kollektion. Ein Anteilstyp ist eine Art Referenz und hat daher keine Eigentümerschaft.

Hier ist ein kleines Programmierproblem: Schreibe eine Funktion, die eine Zeichenkette mit durch Leerzeichen getrennten Wörtern entgegennimmt und das erste Wort zurückgibt, das sie in dieser Zeichenkette findet. Wenn die Funktion kein Leerzeichen in der Zeichenkette findet, muss die gesamte Zeichenkette ein Wort sein, also sollte die gesamte Zeichenkette zurückgegeben werden.

Gehen wir einmal durch, wie wir die Signatur dieser Funktion ohne Verwendung von Anteilstypen schreiben würden, um das Problem zu verstehen, das durch Anteilstypen gelöst wird:

fn first_word(s: &String) -> ?

Die Funktion first_word hat einen &String als Parameter. Wir wollen keine Eigentümerschaft, also ist das in Ordnung. Aber was sollen wir zurückgeben? Wir haben nicht wirklich eine Möglichkeit, über einen Teil einer Zeichenkette zu sprechen. Wir könnten jedoch den Index des Wortendes zurückgeben. Versuchen wir das, wie in Codeblock 4-7 gezeigt.

Dateiname: src/main.rs

#![allow(unused)]
fn main() {
fn first_word(s: &String) -> usize {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return i;
        }
    }

    s.len()
}
}

Codeblock 4-7: Die Funktion first_word, die einen Byte-Indexwert zum Parameter String zurückgibt

Da wir den String Zeichen für Zeichen durchgehen und prüfen müssen, ob ein Wert ein Leerzeichen ist, wandeln wir unseren String mit der Methode as_bytes in ein Byte-Array um.

#![allow(unused)]
fn main() {
fn first_word(s: &String) -> usize {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return i;
        }
    }

    s.len()
}
}

Als nächstes erstellen wir einen Iterator über das Byte-Array, indem wir die Methode iter verwenden:

#![allow(unused)]
fn main() {
fn first_word(s: &String) -> usize {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return i;
        }
    }

    s.len()
}
}

Auf Iteratoren werden wir in Kapitel 13 näher eingehen. Fürs Erste solltest du wissen, dass iter eine Methode ist, die jedes Element in einer Kollektion zurückgibt und dass enumerate das Ergebnis von iter umhüllt und stattdessen jedes Element als Teil eines Tupels zurückgibt. Das erste Element des Tupels, das von enumerate zurückgegeben wird, ist der Index, und das zweite Element ist eine Referenz auf das Element. Das ist etwas bequemer, als den Index selbst zu berechnen.

Da die Methode enumerate ein Tupel zurückgibt, können wir Muster verwenden, um dieses Tupel zu zerlegen. Wir werden uns in Kapitel 6 eingehender mit Mustern befassen. In der for-Schleife spezifizieren wir also ein Muster, das i für den Index im Tupel und &item für das einzelne Byte im Tupel hat. Da wir eine Referenz auf das Element aus .iter().enumerate() erhalten, verwenden wir & im Muster.

Innerhalb der for-Schleife suchen wir mit Hilfe der Byte-Literal-Syntax b' ' nach dem Byte, das das Leerzeichen repräsentiert. Wenn wir ein Leerzeichen finden, geben wir die Position zurück. Andernfalls geben wir die Länge der Zeichenkette zurück, indem wir s.len() verwenden.

#![allow(unused)]
fn main() {
fn first_word(s: &String) -> usize {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return i;
        }
    }

    s.len()
}
}

Wir haben jetzt eine Möglichkeit, den Index des ersten Wortendes in der Zeichenkette herauszufinden, aber es gibt ein Problem. Wir geben ein usize für sich allein zurück, aber die Zahl ist nur aussagekräftig im Kontext des &String. Mit anderen Worten: Da es sich um einen vom String getrennten Wert handelt, gibt es keine Garantie, dass er auch in Zukunft noch gültig ist. Betrachte das Programm in Codeblock 4-8, das die Funktion first_word aus Codeblock 4-7 verwendet.

Dateiname: src/main.rs

fn first_word(s: &String) -> usize {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return i;
        }
    }

    s.len()
}

fn main() {
    let mut s = String::from("Hallo Welt");

    let word = first_word(&s); // word erhält den Wert 5

    s.clear(); // leert die Zeichenkette und macht sie gleich ""

    // word hat noch immer den Wert 5, aber es gibt keine Zeichenkette mehr,
    // mit der wir den Wert 5 sinnvoll verwenden könnten.
    // word ist jetzt völlig ungültig!
}

Codeblock 4-8: Speichern des Ergebnisses des Funktionsaufrufs first_word und anschließendes Ändern des Inhalts der Zeichenkette

Dieses Programm kompiliert fehlerfrei und würde dies auch tun, wenn wir word nach dem Aufruf von s.clear() benutzen würden. Da word überhaupt nicht mit dem Zustand von s verbunden ist, enthält word immer noch den Wert 5. Wir könnten den Wert 5 mit der Variable s verwenden, um zu versuchen, das erste Wort zu extrahieren, aber das wäre ein Fehler, weil sich der Inhalt von s geändert hat, nachdem wir 5 in word gespeichert haben.

Sich darum kümmern zu müssen, dass der Index in word mit den Daten in s konform ist, ist mühsam und fehleranfällig! Das Verwalten dieser Indizes ist noch fehleranfälliger, wenn wir eine Funktion second_word schreiben. Ihre Signatur müsste dann so aussehen:

fn second_word(s: &String) -> (usize, usize) {

Jetzt verfolgen wir einen Anfangs- und einen Endindex, und wir haben noch mehr Werte, die aus Daten in einem bestimmten Zustand berechnet wurden, aber überhaupt nicht an diesen Zustand gebunden sind. Wir haben drei unverbundene Variablen, die synchron gehalten werden müssen.

Glücklicherweise hat Rust eine Lösung für dieses Problem: Zeichenkettenanteilstypen

Zeichenkettenanteilstypen (string slices)

Ein Zeichenkettenanteilstyp (string slice) ist ein Verweis auf einen Teil eines String, und er sieht so aus:

#![allow(unused)]
fn main() {
let s = String::from("Hallo Welt");

let hello = &s[0..5];
let world = &s[6..10];
}

Anstelle einer Referenz auf den gesamten String ist hello eine Referenz auf einen Teil des String, der mit dem zusätzlichen [0..5] spezifiziert ist. Wir erstellen Anteilstypen unter Angabe eines Bereichs innerhalb von Klammern, indem wir [starting_index..ending_index] angeben, wobei starting_index die erste Position im Anteilstyp und ending_index eine Position mehr als die letzte Position im Anteilstyp ist. Intern speichert die Anteilstyp-Datenstruktur die Anfangsposition und die Länge des Anteilstypen, was ending_index minus starting_index entspricht. Im Fall von let world = &s[6..10]; wäre world also ein Anteilstyp, der einen Zeiger auf das Byte bei Index 6 von s mit dem Längenwert 4 enthält.

Abbildung 4-6 stellt dies dar.

Abbildung 4-6: Zeichenkettenanteilstyp, der sich auf einen Teil eines String bezieht

Wenn du mit der Bereichssyntax .. in Rust beim Index 0 beginnen willst, kannst du den Wert vor den zwei Punkte weglassen. Mit anderen Worten sind diese gleich:

#![allow(unused)]
fn main() {
let s = String::from("Hallo");

let slice = &s[0..2];
let slice = &s[..2];
}

Ebenso kannst du den Endindex weglassen, wenn dein Anteilstyp das letzte Byte des String enthält. Das bedeutet, dass diese gleich sind:

#![allow(unused)]
fn main() {
let s = String::from("Hallo");

let len = s.len();

let slice = &s[3..len];
let slice = &s[3..];
}

Du kannst auch beide Werte weglassen, um einen Ausschnitt der gesamten Zeichenkette zu beschreiben. Diese sind also gleichwertig:

#![allow(unused)]
fn main() {
let s = String::from("Hallo");

let len = s.len();

let slice = &s[0..len];
let slice = &s[..];
}

Hinweis: Bereichsindizes bei Zeichenkettenanteilstypen müssen sich nach gültigen UTF-8-Zeichengrenzen richten. Wenn du versuchst, einen Zeichenkettenanteilstyp in der Mitte eines Mehrbyte-Zeichens zu erstellen, wird dein Programm mit einem Fehler abbrechen. Bei der Einführung von Zeichenkettenanteilstypen in diesem Abschnitt gehen wir nur von ASCII aus; eine eingehendere Diskussion der UTF-8-Behandlung findet sich im Abschnitt „UTF-8-kodierten Text in Zeichenketten (strings) ablegen“ in Kapitel 8.

Mit all diesen Informationen im Hinterkopf schreiben wir first_word so um, dass es einen Anteilstyp zurückgibt. Der Typ mit der Bedeutung „Zeichenkettenanteilstyp“ wird &str geschrieben:

Dateiname: src/main.rs

#![allow(unused)]
fn main() {
fn first_word(s: &String) -> &str {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }

    &s[..]
}
}

Den Index für das Wortende erhalten wir auf die gleiche Weise wie in Codeblock 4-7, indem wir nach dem ersten Vorkommen eines Leerzeichens suchen. Wenn wir ein Leerzeichen finden, geben wir einen Zeichenkettenanteilstyp zurück, wobei wir den Anfang der Zeichenkette und den Index des Leerzeichens als Anfangs- bzw. Endindex verwenden.

Wenn wir nun first_word aufrufen, erhalten wir einen einzelnen Wert zurück, der an die zugrundeliegenden Daten gebunden ist. Der Wert setzt sich aus einer Referenz auf den Startpunkt des Anteilstyps und der Anzahl der Elemente im Anteilstyp zusammen.

Die Rückgabe eines Anteilstyps würde auch für eine Funktion second_word funktionieren:

fn second_word(s: &String) -> &str {

Wir haben jetzt eine einfache API, die viel schwieriger durcheinanderzubringen ist, weil der Compiler sicherstellt, dass die Referenzen auf den String gültig bleiben. Erinnere dich an den Fehler im Programm in Codeblock 4-8, als wir den Index bis zum Ende des ersten Wortes erhielten, dann aber die Zeichenkette löschten, sodass unser Index ungültig wurde. Dieser Code war logisch falsch, zeigte aber keine unmittelbaren Fehler. Die Probleme würden sich später zeigen, wenn wir weiterhin versuchen würden, den ersten Wortindex mit einer leeren Zeichenkette zu verwenden. Anteilstypen machen diesen Fehler unmöglich und lassen uns viel früher wissen, dass wir ein Problem mit unserem Code haben. Die Anteilstypen-Variante von first_word führt zu einem Kompilierfehler:

Dateiname: src/main.rs

fn first_word(s: &String) -> &str {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }

    &s[..]
}

fn main() {
    let mut s = String::from("Hallo Welt");

    let word = first_word(&s);

    s.clear(); // Fehler!

    println!("Das erste Wort ist: {}", word);
}

Hier ist der Kompilierfehler:

$ cargo run
   Compiling ownership v0.1.0 (file:///projects/ownership)
error[E0502]: cannot borrow `s` as mutable because it is also borrowed as immutable
  --> src/main.rs:18:5
   |
16 |     let word = first_word(&s);
   |                           -- immutable borrow occurs here
17 | 
18 |     s.clear(); // Fehler!
   |     ^^^^^^^^^ mutable borrow occurs here
19 | 
20 |     println!("Das erste Wort ist: {}", word);
   |                                        ---- immutable borrow later used here

For more information about this error, try `rustc --explain E0502`.
error: could not compile `ownership` (bin "ownership") due to 1 previous error

Erinnere dich an die Ausleihregeln, durch die wir, wenn wir eine unveränderbare Referenz auf etwas haben, nicht noch eine veränderbare Referenz anlegen können. Da clear den String abschneiden muss, muss es eine veränderbare Referenz erhalten. Das println! nach dem Aufruf von clear verwendet die Referenz in word, sodass die unveränderbare Referenz zu diesem Zeitpunkt noch aktiv sein muss. Rust verbietet, dass die veränderbare Referenz in clear und die unveränderbare Referenz in word nicht gleichzeitig existieren, und die Kompilierung schlägt fehl. Rust hat nicht nur die Benutzung unserer API vereinfacht, sondern auch eine ganze Klasse von Fehlern zur Kompilierzeit beseitigt!

Zeichenkettenliterale als Anteilstypen

Erinnere dich, dass wir darüber sprachen, dass Zeichenkettenliterale in der Binärdatei gespeichert werden. Jetzt, da wir über Anteilstypen Bescheid wissen, können wir Zeichenkettenliterale richtig verstehen:

#![allow(unused)]
fn main() {
let s = "Hallo Welt!";
}

Der Typ von s hier ist &str: Es ist ein Anteilstyp, der auf diesen speziellen Punkt der Binärdatei zeigt. Das ist auch der Grund, warum Zeichenkettenliterale unveränderbar sind; &str ist eine unveränderbare Referenz.

Zeichenkettenanteilstypen als Parameter

Das Wissen, dass man Anteilstypen von Literalen und String-Werten erstellen kann, führt uns zu einer weiteren Verbesserung von first_word, und das ist ihre Signatur:

fn first_word(s: &String) -> &str {

Ein erfahrenerer Rust-Entwickler würde stattdessen die in Codeblock 4-9 gezeigte Signatur schreiben, da sie es uns erlaubt, dieselbe Funktion sowohl auf &String-Werte als auch auf &str-Werte anzuwenden.

fn first_word(s: &str) -> &str {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }

    &s[..]
}

fn main() {
    let my_string = String::from("Hallo Welt");

    // `first_word` funktioniert mit Anteilstypen von `String`, ob teilweise oder ganz
    let word = first_word(&my_string[0..6]);
    let word = first_word(&my_string[..]);
    // `first_word` funktioniert auch bei Referenzen auf `String`, die
    // äquivalent zu ganzen Anteilstypen von `String` sind
    let word = first_word(&my_string);

    let my_string_literal = "Hallo Welt";

    // `first_word` funktioniert mit Anteilstypen von Zeichenkettenliteralen, ob teilweise oder ganz
    let word = first_word(&my_string_literal[0..6]);
    let word = first_word(&my_string_literal[..]);

    // Da Zeichenkettenliterale bereits Zeichenkettenanteilstypen sind,
    // funktioniert dies auch ohne die Anteilstypensyntax!
    let word = first_word(my_string_literal);
}

Codeblock 4-9: Verbessern der Funktion first_word durch Verwenden eines Zeichenkettenanteilstyps für den Typ des Parameters s

Wenn wir einen Zeichenkettenanteilstyp haben, können wir diesen direkt übergeben. Wenn wir einen String haben, können wir einen Anteilstyp des String oder eine Referenz auf den String übergeben. Diese Flexibilität nutzt die Vorteile der automatischen Umwandlung, eine Funktionalität, die wir im Abschnitt „Implizite automatische Umwandlung mit Funktionen und Methoden“ in Kapitel 15 behandeln.

Das Definieren einer Funktion, die einen Zeichenkettenanteilstyp statt einer Referenz auf einen String entgegennimmt, macht unsere API allgemeiner und nützlicher, ohne an Funktionalität einzubüßen:

Dateiname: src/main.rs

fn first_word(s: &str) -> &str {
    let bytes = s.as_bytes();

    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }

    &s[..]
}

fn main() {
    let my_string = String::from("Hallo Welt");

    // `first_word` funktioniert mit Anteilstypen von `String`, ob teilweise oder ganz
    let word = first_word(&my_string[0..6]);
    let word = first_word(&my_string[..]);
    // `first_word` funktioniert auch bei Referenzen auf `String`, die
    // äquivalent zu ganzen Anteilstypen von `String` sind
    let word = first_word(&my_string);

    let my_string_literal = "Hallo Welt";

    // `first_word` funktioniert mit Anteilstypen von Zeichenkettenliteralen, ob teilweise oder ganz
    let word = first_word(&my_string_literal[0..6]);
    let word = first_word(&my_string_literal[..]);

    // Da Zeichenkettenliterale bereits Zeichenkettenanteilstypen sind,
    // funktioniert dies auch ohne die Anteilstypensyntax!
    let word = first_word(my_string_literal);
}

Andere Anteilstypen

Zeichenkettenanteilstypen sind, wie du dir vorstellen kannst, spezifisch für Zeichenketten. Es gibt aber auch einen allgemeineren Anteilstyp. Betrachte dieses Array:

#![allow(unused)]
fn main() {
let a = [1, 2, 3, 4, 5];
}

Genauso wie wir vielleicht auf einen Teil einer Zeichenkette verweisen möchten, möchten wir vielleicht auf einen Teil eines Arrays verweisen. Wir würden das so machen:

#![allow(unused)]
fn main() {
let a = [1, 2, 3, 4, 5];

let slice = &a[1..3];

assert_eq!(slice, &[2, 3]);
}

Dieser Anteilstyp hat den Typ &[i32]. Es funktioniert auf die gleiche Weise wie bei Zeichenkettenanteilstypen, indem es eine Referenz auf das erste Element und eine Länge speichert. Du wirst diese Art von Anteilstyp für alle möglichen anderen Kollektionen verwenden. Wir werden diese Kollektionen im Detail besprechen, wenn wir in Kapitel 8 über Vektoren sprechen.

Zusammenfassung

Die Konzepte von Eigentümerschaft, Ausleihen und Anteilstypen gewährleisten Speichersicherheit zur Kompilierzeit in Rust-Programmen. Die Sprache Rust gibt dir Kontrolle über die Speicherverwendung auf die gleiche Weise wie andere Systemprogrammiersprachen, aber dadurch, dass der Eigentümer der Daten diese automatisch aufräumt, wenn der Eigentümer den Gültigkeitsbereich verlässt, bedeutet dies, dass du keinen zusätzlichen Code schreiben und debuggen musst, um diese Kontrolle zu erhalten.

Die Eigentümerschaft wirkt sich auf die Funktionsweise vieler anderer Teile von Rust aus, deshalb werden wir im weiteren Verlauf des Buchs weiter über diese Konzepte sprechen. Lass uns zu Kapitel 5 übergehen und uns das Gruppieren von Datenteilen zu einer struct ansehen.

Strukturen (structs) für zusammenhängende Daten verwenden

Eine Struktur (struct) ist ein benutzerdefinierter Datentyp, mit dem man mehrere zusammenhängende Werte, die eine sinnvolle Gruppe bilden, zusammenpacken und benennen kann. Wenn du mit einer objektorientierten Sprache vertraut bist, ist eine Struktur analog zu den Datenattributen eines Objekts. In diesem Kapitel werden wir Tupel mit Strukturen vergleichen und gegenüberstellen, um auf den bereits vorhandenen Kenntnissen aufzubauen und zu zeigen, wann Strukturen eine bessere Möglichkeit zur Gruppierung von Daten sind.

Wir werden zeigen, wie man Strukturen definiert und instanziiert. Wir werden besprechen, wie man assoziierte Funktionen definiert, insbesondere die Art assoziierter Funktionen, die Methoden genannt werden, um das Verhalten eines Strukturtyps zu spezifizieren. Strukturen und Aufzählungen (enums) (siehe Kapitel 6) sind die Bausteine zum Erstellen neuer Typen in der Domäne deines Programms, mit denen du die Vorteile der Kompilierzeit-Typprüfung von Rust voll ausschöpfen kannst.

Strukturen (structs) definieren und instanziieren

Strukturen (structs) ähneln Tupeln, die im Abschnitt „Der Tupel-Typ“ besprochen wurden. Wie bei Tupeln können die Teile einer Struktur verschiedene Typen haben. Anders als bei Tupeln benennst du jedes Teil, so dass klar ist, was die Werte bedeuten. Durch diese Namen sind Strukturen flexibler als Tupel: Du musst dich nicht auf die Reihenfolge der Daten verlassen, um die Werte einer Instanz zu spezifizieren oder auf sie zuzugreifen.

Um eine Struktur zu definieren, geben wir das Schlüsselwort struct an und benennen die gesamte Struktur. Der Name einer Struktur sollte die Bedeutung der Daten beschreiben, die gruppiert werden. Dann definieren wir innerhalb geschweifter Klammern die Namen und Typen der Datenteile, die wir Felder nennen. Beispielsweise zeigt Codeblock 5-1 eine Struktur, die Informationen über ein Benutzerkonto speichert.

Dateiname: src/main.rs

#![allow(unused)]
fn main() {
struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}
}

Codeblock 5-1: Definition der Struktur User

Um eine Struktur zu verwenden, nachdem wir sie definiert haben, erstellen wir eine Instanz dieser Struktur, indem wir für jedes Feld einen konkreten Wert angeben. Wir erzeugen eine Instanz, indem wir den Namen der Struktur angeben und dann in geschweiften Klammern die Schlüssel: Wert-Paare angeben, wobei die Schlüssel die Namen der Felder und die Werte die Daten sind, die wir in diesen Feldern speichern wollen. Wir müssen die Felder nicht in der gleichen Reihenfolge angeben, in der wir sie in der Struktur deklariert haben. Anders gesagt ist die Strukturdefinition wie eine allgemeine Typvorlage und Instanzen füllen diese Vorlage mit bestimmten Daten aus, um Werte des Typs zu erzeugen. Beispielsweise können wir einen bestimmten Benutzer deklarieren, wie in Codeblock 5-2 zu sehen ist.

Dateiname: src/main.rs

struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

fn main() {
    let user1 = User {
        active: true,
        username: String::from("benutzername123"),
        email: String::from("jemand@example.com"),
        sign_in_count: 1,
    };
}

Codeblock 5-2: Eine Instanz der Struktur User erzeugen

Um auf einen bestimmten Wert in einer Struktur zuzugreifen, verwenden wir die Punktnotation. Um beispielsweise auf die E-Mail-Adresse dieses Benutzers zuzugreifen, verwenden wir user1.email. Wenn die Instanz veränderbar ist, können wir einen Wert ändern, indem wir die Punktnotation verwenden und ihn einem bestimmten Feld zuweisen. Codeblock 5-3 gezeigt, wie der Wert im Feld email einer veränderbaren User-Instanz geändert werden kann.

Dateiname: src/main.rs

struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

fn main() {
    let mut user1 = User {
        active: true,
        username: String::from("benutzername123"),
        email: String::from("jemand@example.com"),
        sign_in_count: 1,
    };

    user1.email = String::from("andere-email@example.com");
}

Codeblock 5-3: Wert im Feld email einer User-Instanz ändern

Beachte, dass die gesamte Instanz veränderbar sein muss. Rust erlaubt es nicht, nur einzelne Felder als veränderbar zu markieren. Wie mit jedem Ausdruck können wir eine neue Instanz der Struktur als letzten Ausdruck im Funktionsrumpf erzeugen, um diese neue Instanz implizit zurückzugeben.

Codeblock 5-4 zeigt eine Funktion build_user, die eine User-Instanz mit der angegebenen E-Mail und dem Benutzernamen zurückgibt. Das Feld active erhält den Wert true und das Feld sign_in_count den Wert 1.

Dateiname: src/main.rs

struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

fn build_user(email: String, username: String) -> User {
    User {
        active: true,
        username: username,
        email: email,
        sign_in_count: 1,
    }
}

fn main() {
    let user1 = build_user(
        String::from("jemand@example.com"),
        String::from("benutzername123"),
    );
}

Codeblock 5-4: Funktion build_user, die eine E-Mail und einen Benutzernamen entgegennimmt und eine User-Instanz zurückgibt

Es ist sinnvoll, den Funktionsparametern dieselben Namen wie die der Strukturfelder zu geben, jedoch ist das Wiederholen der Feldnamen email und username etwas mühsam. Wenn die Struktur mehr Felder hätte, würde das Wiederholen jedes Namens noch lästiger werden. Glücklicherweise gibt es eine praktische Kurznotation!

Kurznotation der Feld-Initialisierung verwenden

Da die Parameter und die Strukturfelder in Codeblock 5-4 die gleichen Namen haben, können wir die Kurznotation der Feld-Initialisierung (field init shorthand syntax) verwenden, um die Funktion build_user so umzuschreiben, dass sie sich unverändert gleich verhält, ohne email und username zu wiederholen, siehe Codeblock 5-5.

Dateiname: src/main.rs

struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

fn build_user(email: String, username: String) -> User {
    User {
        active: true,
        username,
        email,
        sign_in_count: 1,
    }
}

fn main() {
    let user1 = build_user(
        String::from("jemand@example.com"),
        String::from("benutzername123"),
    );
}

Codeblock 5-5: Funktion build_user mit Kurznotation der Feld-Initialisierung, weil die Parameternamen email und username identisch mit den Strukturfeldern sind

Hier erzeugen wir eine neue Instanz der Struktur User, die ein Feld namens email hat. Wir wollen den Wert des Feldes email auf den Wert des Parameters email der Funktion build_user setzen. Da das Feld email und der Parameter email den gleichen Namen haben, brauchen wir nur email statt email: email zu schreiben.

Instanzen aus anderen Instanzen erzeugen mit der Strukturaktualisierungssyntax

Oft ist es hilfreich, eine neue Instanz einer Struktur zu erstellen, die die meisten Werte einer alten Instanz verwendet und nur einige davon verändert. Du kannst dazu die Strukturaktualisierungssyntax (struct update syntax) verwenden.

Zunächst zeigt Codeblock 5-6, wie wir eine neue User-Instanz user2 ohne Aktualisierungssyntax erstellen. Wir setzen einen neuen Wert für email, verwenden aber ansonsten die gleichen Werte von user1, die wir in Codeblock 5-2 erstellt haben.

Dateiname: src/main.rs

struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

fn main() {
    // --abschneiden--
    let user1 = User {
        email: String::from("jemand@example.com"),
        username: String::from("benutzername123"),
        active: true,
        sign_in_count: 1,
    };

    let user2 = User {
        active: user1.active,
        username: user1.username,
        email: String::from("andere@example.com"),
        sign_in_count: user1.sign_in_count,
    };
}

Codeblock 5-6: Erstellen einer neuen User-Instanz unter Verwendung eines Werts von user1.

Durch Verwenden der Strukturaktualisierungssyntax können wir dasselbe Ergebnis mit weniger Code erreichen, wie Codeblock 5-7 zeigt. Die Syntax .. gibt an, dass die restlichen Felder, die nicht explizit gesetzt wurden, den gleichen Wert haben sollen wie die Felder in der gegebenen Instanz.

Dateiname: src/main.rs

struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

fn main() {
    // --abschneiden--
    let user1 = User {
        email: String::from("jemand@example.com"),
        username: String::from("benutzername123"),
        active: true,
        sign_in_count: 1,
    };

    let user2 = User {
        email: String::from("andere@example.com"),
        ..user1
    };
}

Codeblock 5-7: Verwenden der Strukturaktualisierungssyntax, um einen neuen Wert für email in der User-Instanz zu setzen und die restlichen Werte aus der Instanz user1 zu übernehmen

Der Code in Codeblock 5-7 erzeugt auch eine Instanz user2, die einen anderen Wert für email hat, aber die gleichen Werte der Felder username, active und sign_in_count wie user1. Das ..user1 muss an letzter Stelle stehen um festzulegen, dass alle verbleibenden Felder ihre Werte von den entsprechenden Feldern in user1 beziehen sollen, aber wir können Werte für so viele Felder in beliebiger Reihenfolge angeben, unabhängig von der Reihenfolge der Felder in der Strukturdefinition.

Beachte, dass die Strukturaktualisierungssyntax wie eine Zuweisung mit = ist, da sie die Daten verschiebt, wie wir im Abschnitt „Variablen und Daten im Zusammenspiel mit Move“ gesehen haben. In diesem Beispiel können wir user1 nicht mehr als Ganzes verwenden, nachdem wir user2 erzeugt haben, weil der String im Feld username von user1 in user2 verschoben wurde. Hätten wir user2 neue String-Werte für beide Felder email und username gegeben und somit nur die Werte active und sign_in_count von user1 verwendet, wäre user1 auch nach dem Erstellen von user2 noch gültig. Die Typen active und sign_in_count sind Typen, die das Merkmal Copy implementieren, sodass das Verhalten, das wir im Abschnitt „Nur Stapelspeicher-Daten: Kopieren (copy)“ besprochen haben, zutreffen würde.

Verwenden von Tupel-Strukturen ohne benannte Felder um verschiedene Typen zu erzeugen

Du kannst auch Strukturen definieren, die wie Tupel aussehen, sogenannte Tupel-Strukturen (tuple structs). Tupel-Strukturen sind Strukturen, die keine Feldnamen haben, sondern nur die Typen der Felder. Tupel-Strukturen sind hilfreich, wenn du dem gesamten Tupel einen Namen geben und erreichen willst, dass das Tupel einen anderen Typ als die anderen Tupel hat und Feldnamen wie in einer regulären Struktur langatmig oder unnötig wären.

Um eine Tupel-Struktur zu definieren, starte mit dem Schlüsselwort struct, gefolgt vom Strukturnamen und den Typen im Tupel. Nachfolgend ein Beispiel mit Definition und Verwendung zweier Tupel-Strukturen Color und Point:

Dateiname: src/main.rs

struct Color(i32, i32, i32);
struct Point(i32, i32, i32);

fn main() {
    let black = Color(0, 0, 0);
    let origin = Point(0, 0, 0);
}

Beachte, dass die Werte black und origin unterschiedliche Typen haben, weil sie Instanzen unterschiedlicher Tupel-Strukturen sind. Jede von dir definierte Struktur ist ein eigenständiger Typ, auch wenn die Felder innerhalb der Struktur die gleichen Typen haben könnten. Zum Beispiel kann eine Funktion, die einen Parameter vom Typ Color hat, keinen Point als Argument nehmen, obwohl beide Typen aus drei i32-Werten bestehen. Ansonsten ähneln Tupel-Struktur-Instanzen den Tupeln insofern, als dass sie in ihre einzelnen Teile zerlegt werden können, und du kannst ein . gefolgt vom Index verwenden, um auf einen einzelnen Wert zuzugreifen.

Einheitstyp-ähnliche Strukturen ohne Felder

Du kannst auch Strukturen definieren, die gar keine Felder haben! Diese werden Einheitstyp (unit-like structs) genannt, weil sie sich ähnlich zum leeren Tupel () verhalten, das wir im Abschnitt „Der Tupel-Typ“ erwähnt haben. Einheitstypen können in Situationen nützlich sein, in denen du ein Merkmal (trait) zu einem Typ implementieren musst, du aber keine Daten hast, die im Typ gespeichert werden sollen. Wir werden Merkmale in Kapitel 10 besprechen. Hier ist ein Beispiel für die Deklaration und Instanziierung einer Unit-Struktur namens AlwaysEqual:

Dateiname: src/main.rs

struct AlwaysEqual;

fn main() {
    let subject = AlwaysEqual;
}

Um AlwaysEqual zu definieren, verwenden wir das Schlüsselwort struct, den gewünschten Namen und dann ein Semikolon. Geschweifte Klammern und Klammern sind nicht erforderlich! Dann können wir eine Instanz von AlwaysEqual in der Variable subject auf ähnliche Weise erhalten: Mit dem Namen, den wir definiert haben, ohne geschweifte Klammern oder Klammern. Stell dir vor, wir implementieren ein Verhalten für diesen Typ, bei dem jede Instanz immer gleich ist mit jeder Instanz jedes anderen Typs, vielleicht um ein bekanntes Ergebnis für Testzwecke zu haben. Wir bräuchten keine Daten, um dieses Verhalten umzusetzen! In Kapitel 10 wirst du sehen, wie man Merkmale definiert und sie für jeden Typ implementiert, auch für unit-ähnliche Strukturen.

Eigentümerschaft von Strukturdaten

In der Strukturdefinition User in Codeblock 5-1 haben wir den Typ String anstelle von &str verwendet. Dies ist eine bewusste Entscheidung, denn wir wollen, dass Instanzen dieser Struktur all ihre Daten besitzen und diese Daten so lange gültig sind, wie die gesamte Struktur gültig ist.

Bei Strukturen ist es möglich, Referenzen auf Daten zu speichern, die im Besitz von etwas anderem sind, aber das erfordert die Verwendung von Lebensdauern, einer Rust-Funktionalität, die wir in Kapitel 10 besprechen werden. Die Lebensdauer stellt sicher, dass die von einer Struktur referenzierten Daten so lange gültig sind, wie die Struktur gültig ist. Angenommen, du versuchst eine Referenz in einer Struktur zu speichern, ohne eine Lebensdauer anzugeben, wird das nicht funktionieren:

Dateiname: src/main.rs

struct User {
    active: bool,
    username: &str,
    email: &str,
    sign_in_count: u64,
}

fn main() {
    let user1 = User {
        active: true,
        username: "benutzername123",
        email: "jemand@example.com",
        sign_in_count: 1,
    };
}

Der Compiler wird sich beschweren, dass die Lebensdauer nicht angegeben ist:

$ cargo run
   Compiling structs v0.1.0 (file:///projects/structs)
error[E0106]: missing lifetime specifier
 --> src/main.rs:3:15
  |
3 |     username: &str,
  |               ^ expected named lifetime parameter
  |
help: consider introducing a named lifetime parameter
  |
1 ~ struct User<'a> {
2 |     active: bool,
3 ~     username: &'a str,
  |

error[E0106]: missing lifetime specifier
 --> src/main.rs:4:12
  |
4 |     email: &str,
  |            ^ expected named lifetime parameter
  |
help: consider introducing a named lifetime parameter
  |
1 ~ struct User<'a> {
2 |     active: bool,
3 |     username: &str,
4 ~     email: &'a str,
  |

For more information about this error, try `rustc --explain E0106`.
error: could not compile `structs` (bin "structs") due to 2 previous errors

In Kapitel 10 werden wir klären, wie man diese Fehler behebt und Referenzen in Strukturen speichern kann. Aber für den Moment werden wir Fehler wie diese vermeiden, indem wir Typen wie String anstelle von Referenzen wie &str verwenden.

Beispielprogramm mit Strukturen (structs)

Um besser zu verstehen, wann wir Strukturen verwenden können, schreiben wir ein Programm, das die Fläche eines Rechtecks berechnet. Wir beginnen mit einzelnen Variablen und schreiben das Programm dann um, bis wir stattdessen Strukturen einsetzen.

Legen wir mit Cargo ein neues Binärprojekt namens rectangles an, das die Breite und Höhe eines in Pixeln angegebenen Rechtecks nimmt und die Fläche des Rechtecks berechnet. Codeblock 5-8 zeigt ein kurzes Programm, das genau das in src/main.rs unseres Projekts macht.

Dateiname: src/main.rs

fn main() {
    let width1 = 30;
    let height1 = 50;

    println!(
        "Die Fläche des Rechtecks ist {} Quadratpixel.",
        area(width1, height1)
    );
}

fn area(width: u32, height: u32) -> u32 {
    width * height
}

Codeblock 5-8: Berechnen der Fläche eines Rechtecks, das durch separate Breiten- und Höhenvariablen beschrieben wird

Nun führe dieses Programm mit cargo run aus:

$ cargo run
   Compiling structs v0.1.0 (file:///projects/structs)
    Finished dev [unoptimized + debuginfo] target(s) in 0.42s
     Running `target/debug/structs`
Die Fläche des Rechtecks ist 1500 Quadratpixel.

Mit diesem Code gelingt es, die Fläche des Rechtecks zu ermitteln, indem die Funktion area mit jeder Dimension aufgerufen wird. Aber wir können noch mehr tun, um diesen Code klar und lesbar zu machen.

Das Problem dieses Codes wird bei der Signatur von area deutlich:

fn main() {
    let width1 = 30;
    let height1 = 50;

    println!(
        "Die Fläche des Rechtecks ist {} Quadratpixel.",
        area(width1, height1)
    );
}

fn area(width: u32, height: u32) -> u32 {
    width * height
}

Die Funktion area soll die Fläche eines Rechtecks berechnen, aber die von uns geschriebene Funktion hat zwei Parameter und es geht in unserem Programm nirgendwo klar hervor, dass die Parameter zusammenhängen. Es wäre besser lesbar und überschaubarer, Breite und Höhe zusammenzufassen. Eine Möglichkeit dazu haben wir bereits im Abschnitt „Der Tupel-Typ“ in Kapitel 3 vorgestellt: Der Einsatz von Tupeln.

Refaktorierung mit Tupeln

Codeblock 5-9 zeigt eine weitere Version unseres Programms, die Tupel verwendet.

Dateiname: src/main.rs

fn main() {
    let rect1 = (30, 50);

    println!(
        "Die Fläche des Rechtecks ist {} Quadratpixel.",
        area(rect1)
    );
}

fn area(dimensions: (u32, u32)) -> u32 {
    dimensions.0 * dimensions.1
}

Codeblock 5-9: Breite und Höhe des Rechtecks werden mit einem Tupel beschrieben

In einem Punkt ist dieses Programm besser. Das Tupel bringt etwas Struktur hinein und wir geben jetzt nur noch ein Argument weiter. Andererseits ist dieser Ansatz weniger deutlich: Tupel benennen ihre Elemente nicht, sodass wir die Teile des Tupels indizieren müssen, was unsere Berechnung weniger klar macht.

Die Verwechslung von Breite und Höhe ist für die Flächenberechnung nicht von Bedeutung, aber wenn wir das Rechteck auf dem Bildschirm zeichnen wollen, wäre es wichtig! Wir müssen uns merken, dass width der Tupelindex 0 und height der Tupelindex 1 ist. Für andere wäre es noch schwieriger, dies herauszufinden und im Kopf zu behalten, wenn sie unseren Code verwenden würden. Da wir die Bedeutung unserer Daten nicht in unseren Code übertragen haben, ist es jetzt einfacher, Fehler zu machen.

Refaktorierung mit Strukturen: Mehr Semantik

Verwenden wir Strukturen, um durch die Benennung der Daten deren Bedeutung anzugeben. Wir können das verwendete Tupel in eine Struktur mit einem Namen für das Ganze sowie mit Namen für die Einzelteile umwandeln, wie in Codeblock 5-10 gezeigt.

Dateiname: src/main.rs

struct Rectangle {
    width: u32,
    height: u32,
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };

    println!(
        "Die Fläche des Rechtecks ist {} Quadratpixel.",
        area(&rect1)
    );
}

fn area(rectangle: &Rectangle) -> u32 {
    rectangle.width * rectangle.height
}

Codeblock 5-10: Definieren der Struktur Rectangle

Hier haben wir eine Struktur definiert und sie Rectangle genannt. Innerhalb der geschweiften Klammern haben wir die Felder width und height definiert, die beide den Typ u32 haben. Dann erzeugten wir in main eine Instanz von Rectangle mit der Breite 30 und Höhe 50.

Unsere Funktion area hat nun einen Parameter, den wir rectangle genannt haben und dessen Typ eine unveränderbare Ausleihe (immutable borrow) einer Strukturinstanz Rectangle ist. Wie in Kapitel 4 erwähnt, wollen wir die Struktur nur ausleihen, nicht aber deren Eigentümerschaft (ownership) übernehmen. Auf diese Weise behält main seine Eigentümerschaft und kann weiterhin rect1 verwenden, weshalb wir & in der Funktionssignatur und an der Aufrufstelle verwenden.

Die Funktion area greift auf die Felder width und height der Instanz Rectangle zu. (Beachte, dass der Zugriff auf Felder einer ausgeliehenen Struktur-Instanz die Feldwerte nicht verschiebt, weshalb du häufig Ausleihen von Strukturen siehst.) Unsere Funktionssignatur für area sagt jetzt genau, was wir meinen: Berechne die Fläche von Rectangle unter Verwendung seiner Felder width und height. Dies drückt aus, dass Breite und Höhe in Beziehung zueinander stehen, und gibt den Werten beschreibende Namen, ohne die Tupelindexwerte 0 und 1 zu verwenden. Das erhöht die Lesbarkeit.

Hilfreiche Funktionalität mit abgeleiteten Merkmalen (derived traits)

Es wäre hilfreich, eine Instanz von Rectangle samt der Werte seiner Felder ausgeben zu können, während wir unser Programm debuggen. In Codeblock 5-11 versuchen wir, das Makro println! zu verwenden, das wir in den vorangegangenen Kapiteln verwendet haben. Dies wird jedoch nicht funktionieren.

Dateiname: src/main.rs

struct Rectangle {
    width: u32,
    height: u32,
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };

    println!("rect1 ist {}", rect1);
}

Codeblock 5-11: Versuch, eine Rectangle-Instanz auszugeben

Wenn wir diesen Code kompilieren, erhalten wir folgende Fehlermeldung:

error[E0277]: `Rectangle` doesn't implement `std::fmt::Display`

Das Makro println! kann diverse Formatierungen vornehmen. Die geschweiften Klammern weisen println! an, die Formatierung Display zu verwenden, bei der die Ausgabe direkt für den Endbenutzer bestimmt ist. Die primitiven Typen, die wir bisher gesehen haben, implementieren Display standardmäßig, denn es gibt nur eine Möglichkeit, dem Benutzer eine 1 oder einen anderen primitiven Typ zu zeigen. Aber bei Strukturen ist die Formatierung, die println! verwenden soll, weniger klar, da es mehrere Darstellungsmöglichkeiten gibt: Möchtest du Kommas oder nicht? Möchtest du die geschweiften Klammern ausgeben? Sollen alle Felder angezeigt werden? Aufgrund der vielen Möglichkeiten versucht Rust nicht zu erraten, was wir wollen. Strukturen haben daher keine Standardimplementierung von Display, um die mit println! und dem Platzhalter {} verwenden zu können.

Wenn wir die Fehlerausgabe weiterlesen, werden wir diesen hilfreichen Hinweis finden:

   = help: the trait `std::fmt::Display` is not implemented for `Rectangle`
   = note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead

Lass es uns versuchen! Der Makroaufruf println! wird geändert in println!("rect1 ist {:?}", rect1);. Wenn wir das Symbol :? innerhalb der geschweiften Klammern angeben, teilen wir println! mit, dass wir das Ausgabeformat Debug verwenden wollen. Das Merkmal Debug ermöglicht es, die Struktur so auszugeben, dass Entwickler ihren Wert erkennen können, während sie den Code debuggen.

Kompiliere den Code mit dieser Änderung. Verflixt! Wir erhalten immer noch einen Fehler:

error[E0277]: `Rectangle` doesn't implement `Debug`

Aber auch hier gibt uns der Compiler einen hilfreichen Hinweis:

   = help: the trait `std::fmt::Debug` is not implemented for `Rectangle`
   = note: add `#[derive(Debug)]` or manually implement `std::fmt::Debug`

Rust enthält durchaus eine Funktionalität zum Ausgeben von Debug-Informationen, aber wir müssen diese explizit für unsere Struktur aktivieren. Dazu fügen wir das äußere Attribut #[derive(Debug)] unmittelbar vor der Strukturdefinition ein, wie in Codeblock 5-12 gezeigt.

Dateiname: src/main.rs

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };

    println!("rect1 ist {:?}", rect1);
}

Codeblock 5-12: Attribut zum Verwenden des Merkmals Debug und Ausgeben der Instanz Rectangle mittels Debug-Formatierung

Wenn wir das Programm nun ausführen, werden wir keinen Fehler mehr erhalten und folgende Ausgabe sehen:

$ cargo run
   Compiling structs v0.1.0 (file:///projects/structs)
    Finished dev [unoptimized + debuginfo] target(s) in 0.48s
     Running `target/debug/structs`
rect1 ist Rectangle { width: 30, height: 50 }

Toll! Es ist nicht die schönste Ausgabe, aber sie zeigt die Werte aller Felder dieser Instanz, was bei der Fehlersuche definitiv hilfreich ist. Bei größeren Strukturen ist es hilfreich, eine leichter lesbare Ausgabe zu erhalten. In diesen Fällen können wir {:#?} anstelle von {:?} in der println!-Meldung verwenden. In diesem Beispiel wird bei Verwendung von {:#?} folgendes ausgegeben:

$ cargo run
   Compiling structs v0.1.0 (file:///projects/structs)
    Finished dev [unoptimized + debuginfo] target(s) in 0.48s
     Running `target/debug/structs`
rect1 ist Rectangle {
    width: 30,
    height: 50,
}

Eine andere Möglichkeit, einen Wert im Debug-Format auszugeben, ist die Verwendung des Makros dbg!, das die Eigentümerschaft eines Ausdrucks übernimmt (im Gegensatz zu println!, das eine Referenz nimmt), die Datei und Zeilennummer, in der der dbg!-Makroaufruf in deinem Code vorkommt, zusammen mit dem resultierenden Wert des Ausdrucks ausgibt und die Eigentümerschaft am Wert zurückgibt.

Hinweis: Der Aufruf des Makros dbg! schreibt in die Standardfehlerausgabe (stderr), im Gegensatz zu println!, das in die Standardausgabe (stdout) schreibt. Wir werden mehr über stderr und stdout im Abschnitt „Fehlermeldungen in die Standardfehlerausgabe anstatt der Standardausgabe schreiben“ in Kapitel 12 erfahren.

Hier ist ein Beispiel, bei dem wir am Wert interessiert sind, der dem Feld width zugewiesen wird, als auch am Wert der gesamten Struktur in rect1:

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

fn main() {
    let scale = 2;
    let rect1 = Rectangle {
        width: dbg!(30 * scale),
        height: 50,
    };

    dbg!(&rect1);
}

Wir können dbg! um den Ausdruck 30 * scale setzen, und da dbg! die Eigentümerschaft des Werts des Ausdrucks zurückgibt, erhält das Feld width denselben Wert, als wenn wir den dbg!-Aufruf dort nicht hätten. Wir wollen nicht, dass dbg! die Eigentümerschaft von rect1 übernimmt, also übergeben wir eine Referenz auf rect1 im nächsten Aufruf. So sieht die Ausgabe dieses Beispiels aus:

$ cargo run
   Compiling rectangles v0.1.0 (file:///projects/rectangles)
    Finished dev [unoptimized + debuginfo] target(s) in 0.61s
     Running `target/debug/rectangles`
[src/main.rs:10:16] 30 * scale = 60
[src/main.rs:14:5] &rect1 = Rectangle {
    width: 60,
    height: 50,
}

Wir können sehen, dass der erste Teil der Ausgabe von src/main.rs Zeile 10 stammt, wo wir den Ausdruck 30 * scale debuggen, und der Ergebniswert ist 60 (die Debug-Formatierung, die für Ganzzahlen implementiert ist, gibt nur deren Wert aus). Der dbg!-Aufruf in Zeile 14 von src/main.rs gibt den Wert von &rect1 aus, der die Struktur Rectangle ist. Diese Ausgabe verwendet die hübsche Debug-Formatierung des Typs Rectangle. Das Makro dbg! kann sehr hilfreich sein, wenn du versuchst, herauszufinden, was dein Code macht!

Zusätzlich zum Merkmal Debug hat Rust eine Reihe von Merkmalen für uns bereitgestellt, die wir mit dem Attribut derive verwenden können und die unseren benutzerdefinierten Typen nützliches Verhalten verleihen können. Diese Merkmale und ihr Verhalten sind in Anhang C aufgeführt. In Kapitel 10 werden wir behandeln, wie man diese Merkmale mit benutzerdefiniertem Verhalten implementiert und wie man eigene Merkmale erstellt. Es gibt auch viele andere Attribute als derive; für weitere Informationen, siehe den Abschnitt „Attribute“ in der Rust-Referenz.

Unsere Funktion area ist sehr spezifisch: Sie berechnet nur die Fläche von Rechtecken. Es wäre hilfreich, dieses Verhalten enger mit unserer Struktur Rectangle zu verbinden, da es zu keinem anderen Typ passt. Schauen wir uns an, wie wir den Code weiter umgestalten und unsere Funktion area in eine Methode area unseres Typs Rectangle verwandeln können.

Methodensyntax

Methoden sind Funktionen recht ähnlich: Sie werden mit dem Schlüsselwort fn und ihrem Namen deklariert, sie können Parameter und einen Rückgabewert haben, und sie enthalten etwas Code, der ausgeführt wird, wenn sie aufgerufen werden. Methoden unterscheiden sich jedoch von Funktionen dadurch, dass sie im Kontext einer Struktur (struct) (oder einer Aufzählung (enum) oder eines Merkmalsobjektes (trait object), die wir in Kapitel 6 und Kapitel 17 behandeln) definiert werden und ihr erster Parameter stets self ist. self repräsentiert die Instanz der Struktur, zu der die Methode aufgerufen wird.

Definieren von Methoden

Lass uns die Funktion area, die eine Rectangle-Instanz als Parameter hat, ändern und stattdessen eine Methode area auf der Struktur Rectangle definieren, wie in Codeblock 5-13 zu sehen ist.

Dateiname: src/main.rs

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn area(&self) -> u32 {
        self.width * self.height
    }
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };

    println!(
        "Die Fläche des Rechtecks ist {} Quadratpixel.",
        rect1.area()
    );
}

Codeblock 5-13: Methode area der Struktur Rectangle

Um die Funktion im Kontext von Rectangle zu definieren, beginnen wir mit dem Block impl (Implementierung) für Rectangle. Alles in diesem Block wird mit dem Typ Rectangle assoziiert. Dann verschieben wir die Funktion area in die geschweiften Klammern von impl, ändern den ersten (und in diesem Fall einzigen) Parameter zu self und passen den Methodenrumpf entsprechend an. In main, wo wir die Funktion area aufrufen und rect1 als Argument übergeben, können wir stattdessen die Methodensyntax verwenden, um die Methode area auf unserer Rectangle-Instanz aufzurufen. Die Methodensyntax bezieht sich auf eine Instanz: Wir ergänzen einen Punkt, gefolgt vom Methodennamen, Klammern und Argumenten.

In der Signatur von area verwenden wir &self anstelle von rectangle: &Rectangle. Das &self ist eigentlich die Abkürzung für self: &Self. Innerhalb eines impl-Blocks ist der Typ Self ein Alias für den Typ, für den der impl-Block steht. Methoden müssen einen Parameter mit dem Namen self vom Typ Self als ihren ersten Parameter haben, Rust lässt dich dies abkürzen, indem du nur den Namen self an der Stelle des ersten Parameters angibst. Beachte, dass wir immer noch das & vor der Abkürzung self verwenden müssen, um anzuzeigen, dass diese Methode die Instanz Self ausleiht, genau wie in rectangle: &Rectangle. Methoden können die Eigentümerschaft von self übernehmen, self unveränderbar ausleihen, wie wir es hier getan haben, oder self veränderbar ausleihen, so wie bei jedem anderen Parameter auch.

Wir haben hier &self aus dem gleichen Grund gewählt wie &Rectangle in der Funktionsvariante: Wir wollen keine Eigentümerschaft übernehmen, wir wollen die Daten der Struktur nur lesen, nicht schreiben. Wenn wir die Instanzdaten ändern wollten, müssten wir &mut self als ersten Parameter verwenden. Es kommt nur selten vor, dass eine Methode die Eigentümerschaft der Instanz übernimmt, indem sie self als ersten Parameter verwendet. Diese Technik wird typischerweise dann verwendet, wenn die Methode self in etwas anderes transformiert und man verhindern will, dass der Aufrufer nach der Transformation die ursprüngliche Instanz verwendet.

Der Hauptgrund für Methoden gegenüber Funktionen liegt abgesehen davon, dass bei jeder Methodendeklaration der Typ von self nicht ständig wiederholt werden muss, in der Organisation. Wir haben alle Dinge, die wir mit einer Instanz eines Typs tun können, in einen einzigen impl Block gepackt. Zukünftige Nutzer unseres Codes müssen so nicht an verschiedenen Stellen in der von uns bereitgestellten Bibliothek nach Fähigkeiten von Rectangle suchen.

Beachte, dass wir einer Methode denselben Namen geben können wie einem der Felder der Struktur. Zum Beispiel können wir eine Methode auf Rectangle definieren, die ebenfalls width heißt:

Dateiname: src/main.rs

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn width(&self) -> bool {
        self.width > 0
    }
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };

    if rect1.width() {
        println!("Das Rechteck hat eine Breite ungleich Null; sie ist {}", rect1.width);
    }
}

Hier entscheiden wir uns dafür, dass die Methode width den Wert true zurückgibt, wenn der Wert im Feld width der Instanz größer als 0 ist, und false, wenn der Wert 0 ist: Wir können ein Feld innerhalb einer gleichnamigen Methode für jeden Zweck verwenden. Wenn wir in main nach rect1.width eine Klammer setzen, weiß Rust, dass wir die Methode width meinen. Wenn wir keine Klammern verwenden, weiß Rust, dass wir das Feld width meinen.

Oft, aber nicht immer, wird eine Methode mit demselben Namen wie ein Feld so definiert, dass sie nur den Wert des Feldes zurückgeben und nichts anderes tun. Methoden wie diese werden getters genannt, und Rust implementiert sie nicht automatisch für Strukturfelder, wie es einige andere Sprachen tun. Getter sind nützlich, weil man das Feld als privat, die Methode aber als öffentlich kennzeichnen und so den Nur-Lese-Zugriff auf dieses Feld als Teil der öffentlichen API des Typs erhält. Was öffentlich und privat bedeuten und wie man ein Feld oder eine Methode als öffentlich oder privat kennzeichnet, werden wir in Kapitel 7 behandeln.

Wo ist der Operator ->?

In C und C++ werden zwei verschiedene Operatoren für den Aufruf von Methoden verwendet: Man verwendet ., wenn eine Methode direkt auf dem Objekt aufgerufen wird, und ->, wenn die Methode auf einem Zeiger auf das Objekt aufrufen und der Zeiger zuerst dereferenziert werden muss. Anders gesagt, wenn object ein Zeiger ist, ist object->something() ähnlich zu (*object).something().

Rust hat kein Äquivalent zum Operator ->. Stattdessen hat Rust eine Funktionalität namens automatische Referenzierung und Dereferenzierung (automatic referencing and dereferencing). Der Aufruf von Methoden ist einer der wenigen Orte in Rust, der dieses Verhalten aufweist.

Und so funktioniert es: Wenn du eine Methode mit object.something() aufrufst, fügt Rust automatisch &, &mut oder * hinzu, sodass object zur Signatur der Methode passt. Mit anderen Worten sind folgende Aufrufe gleich:

#![allow(unused)]
fn main() {
#[derive(Debug,Copy,Clone)]
struct Point {
    x: f64,
    y: f64,
}

impl Point {
   fn distance(&self, other: &Point) -> f64 {
       let x_squared = f64::powi(other.x - self.x, 2);
       let y_squared = f64::powi(other.y - self.y, 2);

       f64::sqrt(x_squared + y_squared)
   }
}
let p1 = Point { x: 0.0, y: 0.0 };
let p2 = Point { x: 5.0, y: 6.5 };
p1.distance(&p2);
(&p1).distance(&p2);
}

Der erste Aufruf sieht viel sauberer aus. Die automatische Referenzierung funktioniert, weil Methoden einen eindeutigen Empfänger haben - den Typ von self. Wenn man den Empfänger und den Namen einer Methode angibt, kann Rust eindeutig herausfinden, ob die Methode lesend (&self), veränderbar (&mut self) oder konsumierend (self) ist. Die Tatsache, dass Rust das Ausleihen für die Methodenempfänger implizit macht, ist ein großer Beitrag zur Ergonomie der Eigentümerschaft in der Praxis.

Methoden mit mehreren Parametern

Lass uns den Umgang mit Methoden üben, indem wir eine zweite Methode zur Struktur Rectangle implementieren. Diesmal soll eine zweite Instanz von Rectangle entgegengenommen und true zurückgeben werden, wenn das zweite Rectangle vollständig in self (dem ersten Rectangle) hineinpasst; andernfalls soll false zurückgegeben werden. Das heißt, sobald wir die Methode can_hold definiert haben, wollen wir in der Lage sein, das in Codeblock 5-14 gezeigte Programm zu schreiben.

Dateiname: src/main.rs

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };
    let rect2 = Rectangle {
        width: 10,
        height: 40,
    };
    let rect3 = Rectangle {
        width: 60,
        height: 45,
    };

    println!("Umfasst rect1 rect2? {}", rect1.can_hold(&rect2));
    println!("Umfasst rect1 rect3? {}", rect1.can_hold(&rect3));
}

Codeblock 5-14: Verwendung der noch nicht geschriebenen Methode can_hold

Die erwartete Ausgabe würde wie folgt aussehen, da beide Dimensionen von rect2 kleiner als die Dimensionen von rect1 sind, aber rect3 breiter als rect1 ist:

Umfasst rect1 rect2? true
Umfasst rect1 rect3? false

Wir wissen, dass wir eine Methode definieren wollen, also wird sie innerhalb des Blocks impl Rectangle liegen. Die Methode wird can_hold heißen und sie wird einen weiteren Parameter vom Typ Rectangle unveränderbar ausleihen. Wir können den Typ des Parameters erkennen, indem wir uns den Code ansehen, der die Methode aufruft: rect1.can_hold(&rect2) nimmt &rect2 entgegen, also eine unveränderbare Ausleihe von rect2 vom Typ Rectangle. Das macht Sinn, da wir rect2 nur lesen müssen (anstatt zu schreiben, wofür wir eine veränderbare Ausleihe bräuchten) und main die Eigentümerschaft an rect2 zurückerhalten soll, sodass wir es nach dem Aufruf der Methode can_hold weiter verwenden können. Der Rückgabewert von can_hold ist ein boolescher Wert und die Implementierung prüft, ob Breite und Höhe von self jeweils größer als von Rectangle sind. Fügen wir die neue Methode can_hold zum Block impl aus Codeblock 5-13 hinzu, wie in Codeblock 5-15 gezeigt.

Dateiname: src/main.rs

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn area(&self) -> u32 {
        self.width * self.height
    }

    fn can_hold(&self, other: &Rectangle) -> bool {
        self.width > other.width && self.height > other.height
    }
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };
    let rect2 = Rectangle {
        width: 10,
        height: 40,
    };
    let rect3 = Rectangle {
        width: 60,
        height: 45,
    };

    println!("Umfasst rect1 rect2? {}", rect1.can_hold(&rect2));
    println!("Umfasst rect1 rect3? {}", rect1.can_hold(&rect3));
}

Codeblock 5-15: Implementierung der Methode can_hold auf Rectangle, die eine weitere Rectangle-Instanz als Parameter hat

Wenn wir diesen Code mit der Funktion main in Codeblock 5-14 ausführen, erhalten wir die gewünschte Ausgabe. Methoden können mehrere Parameter haben, die wir in der Signatur nach dem Parameter self angeben. Diese Parameter funktionieren genau wie Parameter in Funktionen.

Assoziierte Funktionen

Alle Funktionen, die innerhalb eines impl-Blocks definiert sind, werden assoziierte Funktionen genannt, weil sie mit dem Typ assoziiert sind, der nach dem impl benannt ist. Wir können assoziierte Funktionen definieren, die nicht self als ihren ersten Parameter haben (und somit keine Methoden sind), weil sie keine Instanz des Typs benötigen, um damit zu arbeiten. Wir haben bereits eine solche Funktion verwendet: Die Funktion String::from, die für den Typ String definiert ist.

Assoziierte Funktionen, die keine Methoden sind, werden oft als Konstruktoren verwendet, die eine neue Instanz der Struktur zurückgeben. Diese werden oft als new bezeichnet, aber new ist kein spezieller Name und ist nicht in die Sprache eingebaut. Wir könnten zum Beispiel eine assoziierte Funktion mit dem Namen square bereitstellen, die einen eindimensionalen Parameter hat und diesen sowohl für die Breite als auch für die Höhe verwendet, sodass es einfacher ist, ein quadratisches Rectangle zu erstellen, anstatt denselben Wert zweimal angeben zu müssen:

Dateiname: src/main.rs

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn square(size: u32) -> Self {
        Self {
            width: size,
            height: size,
        }
    }
}

fn main() {
    let sq = Rectangle::square(3);
}

Die Schlüsselwörter Self im Rückgabetyp und im Rumpf der Funktion sind Aliase für den Typ, der nach dem Schlüsselwort impl steht, in diesem Fall Rectangle.

Um diese assoziierte Funktion aufzurufen, verwenden wir die Syntax :: mit dem Strukturnamen, z.B. let sq = Rectangle::square(3);. Diese Funktion gehört zum Namensraum der Struktur: Die Syntax :: wird sowohl für assoziierte Funktionen als auch für Namensräume, die von Modulen erzeugt werden, verwendet. Wir werden die Module in Kapitel 7 besprechen.

Mehrere impl-Blöcke

Jede Struktur darf mehrere impl-Blöcke haben. Beispielsweise entspricht Codeblock 5-15 dem in Codeblock 5-16 gezeigten Code, bei dem jede Methode in einem eigenen impl-Block steht.

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn area(&self) -> u32 {
        self.width * self.height
    }
}

impl Rectangle {
    fn can_hold(&self, other: &Rectangle) -> bool {
        self.width > other.width && self.height > other.height
    }
}

fn main() {
    let rect1 = Rectangle {
        width: 30,
        height: 50,
    };
    let rect2 = Rectangle {
        width: 10,
        height: 40,
    };
    let rect3 = Rectangle {
        width: 60,
        height: 45,
    };

    println!("Umfasst rect1 rect2? {}", rect1.can_hold(&rect2));
    println!("Umfasst rect1 rect3? {}", rect1.can_hold(&rect3));
}

Codeblock 5-16: Neuschreiben von Codeblock 5-15 unter Verwendung mehrerer impl-Blöcke

Es ist nicht nötig, diese Methoden hier auf mehrere impl-Blöcke zu verteilen, aber es handelt sich um eine gültige Syntax. Wir werden in Kapitel 10 einen Fall sehen, bei dem mehrere impl-Blöcke hilfreich sind, wenn wir generische Typen und Merkmale behandeln.

Zusammenfassung

Mit Strukturen kannst du benutzerdefinierte Typen erstellen, die in deiner Domäne eine Bedeutung haben. Durch die Verwendung von Strukturen kannst du zusammengehörige Datenteile miteinander verbunden halten und jedes Teil benennen, um deinen Code verständlich zu machen. In impl-Blöcken kannst du Funktionen definieren, die mit deinem Typ assoziiert sind, und Methoden sind eine Art assoziierte Funktion, mit der du das Verhalten von Instanzen deiner Strukturen festlegen kannst.

Aber Strukturen sind nicht die einzige Möglichkeit, benutzerdefinierte Typen zu definieren: Wenden wir uns der Rust-Funktionalität Aufzählung zu, um ein weiteres Werkzeug in deinen Werkzeugkasten zu legen.

Aufzählungen (enums) und Musterabgleich (pattern matching)

In diesem Kapitel werden wir uns mit Aufzählungen (enumerations, kurz: enums) befassen. Aufzählungen erlauben es, einen Typ durch Aufzählung seiner möglichen Varianten (variants) zu definieren. Zuerst werden wir eine Aufzählung definieren und verwenden, um zu zeigen, wie eine Aufzählung mit Daten eine Bedeutung kodieren kann. Als Nächstes werden wir eine besonders nützliche Aufzählung untersuchen, die Option genannt wird und zum Ausdruck bringt, dass ein Wert entweder etwas oder nichts sein kann. Dann sehen wir uns an, wie man mit dem Musterabgleich (pattern matching) im Ausdruck match auf einfache Weise unterschiedlichen Code für verschiedene Werte einer Aufzählung auszuführen kann. Schließlich werden wir uns mit dem Konstrukt if let befassen, einem weiteren bequemen und prägnanten Idiom, um mit Aufzählungen in deinem Code umzugehen.

Eine Aufzählung (enum) definieren

Während Strukturen (structs) eine Möglichkeit bieten, zusammengehörige Felder und Daten zu gruppieren, wie ein Rectangle mit seiner width und height, bieten Aufzählungen (enums) eine Möglichkeit, einen Wert als einen aus einer möglichen Gruppe von Werten anzugeben. Wir können zum Beispiel sagen, dass Rectangle eine von mehreren möglichen Formen ist, zu denen auch Circle und Triangle gehören. Um dies zu tun, erlaubt Rust uns, diese Möglichkeiten als Aufzählung zu kodieren.

Schauen wir uns eine Situation an, die wir vielleicht in Code ausdrücken wollen, und sehen wir, warum Aufzählungen in diesem Fall nützlich und besser geeignet sind als Strukturen. Angenommen, wir müssen mit IP-Adressen arbeiten. Aktuell werden zwei Hauptstandards für IP-Adressen verwendet: Version vier und Version sechs. Da dies die einzigen Möglichkeiten für eine IP-Adresse sind, auf die unser Programm stößt, können wir alle möglichen Varianten aufzählen, woher die Aufzählung ihren Namen hat.

Jede IP-Adresse kann entweder eine Adresse der Version vier oder der Version sechs sein, aber nicht beides gleichzeitig. Diese Eigenschaft der IP-Adressen passt zur Aufzählungs-Datenstruktur, da ein Aufzählungswert nur eine seiner Varianten sein kann. Sowohl die Adressen der Version vier als auch der Version sechs sind grundsätzlich immer noch IP-Adressen, sodass sie als der gleiche Typ behandelt werden sollten, wenn der Code mit Situationen zu tun hat, die für beide IP-Adressenarten gelten.

Wir können dieses Konzept im Code ausdrücken, indem wir eine Aufzählung IpAddrKind definieren und die möglichen Varianten auflisten, die eine IP-Adresse haben kann, V4 und V6. Hier die Varianten der Aufzählung:

enum IpAddrKind {
    V4,
    V6,
}

fn main() {
    let four = IpAddrKind::V4;
    let six = IpAddrKind::V6;

    route(IpAddrKind::V4);
    route(IpAddrKind::V6);
}

fn route(ip_kind: IpAddrKind) {}

IpAddrKind ist jetzt ein benutzerdefinierter Datentyp, den wir an anderer Stelle in unserem Code verwenden können.

Werte in Aufzählungen

Wir können Instanzen von beiden Varianten von IpAddrKind wie folgt erstellen:

enum IpAddrKind {
    V4,
    V6,
}

fn main() {
    let four = IpAddrKind::V4;
    let six = IpAddrKind::V6;

    route(IpAddrKind::V4);
    route(IpAddrKind::V6);
}

fn route(ip_kind: IpAddrKind) {}

Beachte, dass die Varianten der Aufzählung mit dem Namensraum des Bezeichners angegeben sind und wir einen doppelten Doppelpunkt verwenden, um die beiden zu trennen. Das ist sinnvoll, weil beide Werte IpAddrKind::V4 und IpAddrKind::V6 vom gleichen Typ sind: IpAddrKind. Wir können dann zum Beispiel eine Funktion definieren, die jedes IpAddrKind annimmt:

enum IpAddrKind {
    V4,
    V6,
}

fn main() {
    let four = IpAddrKind::V4;
    let six = IpAddrKind::V6;

    route(IpAddrKind::V4);
    route(IpAddrKind::V6);
}

fn route(ip_kind: IpAddrKind) {}

Und wir können diese Funktion mit beiden Varianten aufrufen:

enum IpAddrKind {
    V4,
    V6,
}

fn main() {
    let four = IpAddrKind::V4;
    let six = IpAddrKind::V6;

    route(IpAddrKind::V4);
    route(IpAddrKind::V6);
}

fn route(ip_kind: IpAddrKind) {}

Aufzählungen haben noch weitere Vorteile. Wenn wir weiter über unseren IP-Adresstyp nachdenken, haben wir im Moment keine Möglichkeit, den Wert der tatsächlichen IP-Adresse zu speichern; wir wissen nur, um welche Variante es sich handelt. Mit dem was du gerade erst in Kapitel 5 über Strukturen gelernt hast, könntest du versucht sein, dieses Problem mit Strukturen zu lösen, wie in Codeblock 6-1.

#![allow(unused)]
fn main() {
enum IpAddrKind {
    V4,
    V6,
}

struct IpAddr {
    kind: IpAddrKind,
    address: String,
}

let home = IpAddr {
    kind: IpAddrKind::V4,
    address: String::from("127.0.0.1"),
};

let loopback = IpAddr {
    kind: IpAddrKind::V6,
    address: String::from("::1"),
};
}

Codeblock 6-1: Speichern des Wertes und der IpAddrKind-Variante einer IP-Adresse mittels struct

Hier haben wir eine Struktur IpAddr definiert, die zwei Felder hat: Ein Feld kind vom Typ IpAddrKind (die zuvor definierte Aufzählung) und ein Feld address vom Typ String. Wir haben zwei Instanzen dieser Struktur erzeugt. Die erste ist home und hat die Variante IpAddrKind::V4 und die zugehörige Adresse 127.0.0.1. Die zweite Instanz ist loopback und hat die Variante V6 von IpAddrKind als ihren Wert für kind und die zugehörige Adresse ::1. Wir haben eine Struktur verwendet, um die Werte kind und address zu bündeln, sodass jetzt die Variante mit dem Wert verbunden ist.

Allerdings ist die Darstellung desselben Konzepts mit einer Aufzählung prägnanter: Anstelle einer Aufzählung innerhalb einer Struktur können wir die Daten direkt in jede Aufzählungsvariante einfügen. Diese neue Definition der Aufzählung IpAddr legt fest, dass sowohl die Variante V4 als auch V6 zugehörige String-Werte haben:

#![allow(unused)]
fn main() {
enum IpAddr {
    V4(String),
    V6(String),
}

let home = IpAddr::V4(String::from("127.0.0.1"));

let loopback = IpAddr::V6(String::from("::1"));
}

Wir hängen die Daten direkt an jede Variante der Aufzählung an, so dass keine zusätzliche Struktur erforderlich ist. Hier ist es auch einfacher, ein weiteres Detail der Funktionsweise von Aufzählungen zu betrachten: Der Name jeder Aufzählungs-Variante, die wir definieren, wird auch zu einer Funktion, die eine Instanz der Aufzählung konstruiert. Das heißt, IpAddr::V4() ist ein Funktionsaufruf der ein String-Argument entgegennimmt und eine Instanz des Typs IpAddr zurückgibt. Diese Konstruktorfunktion wird automatisch definiert als Ergebnis der Definition der Aufzählung.

Es gibt noch einen weiteren Vorteil, eine Aufzählung statt einer Struktur zu verwenden: Jede Variante kann verschiedene Typen und verschieden viele zugehöriger Daten haben. IP-Adressen der Version vier haben stets vier numerische Komponenten, die Werte zwischen 0 und 255 haben. Wenn wir V4-Adressen als vier u8-Werte speichern und V6-Adressen als einen String-Wert ausdrücken wollten, wäre das mit einer Struktur nicht möglich. Aufzählungen lösen diesen Fall ganz einfach:

#![allow(unused)]
fn main() {
enum IpAddr {
    V4(u8, u8, u8, u8),
    V6(String),
}

let home = IpAddr::V4(127, 0, 0, 1);

let loopback = IpAddr::V6(String::from("::1"));
}

Wir haben verschiedene Möglichkeiten zur Definition von Datenstrukturen gezeigt, die Version vier und sechs einer IP-Adresse speichern können. Wie sich jedoch herausstellt, ist der Wunsch, IP-Adressen inklusive deren Variante zu speichern, so verbreitet, dass die Standardbibliothek eine Definition bereitstellt, die wir verwenden können! Schauen wir uns an, wie die Standardbibliothek IpAddr definiert: Es hat genau die Aufzählung und die Varianten, die wir definiert und verwendet haben, aber es bettet die Adressdaten innerhalb der Varianten in Form von zwei verschiedenen Strukturen ein, die für jede Variante unterschiedlich definiert sind:

#![allow(unused)]
fn main() {
struct Ipv4Addr {
    // --abschneiden--
}

struct Ipv6Addr {
    // --abschneiden--
}

enum IpAddr {
    V4(Ipv4Addr),
    V6(Ipv6Addr),
}
}

Dieser Code veranschaulicht, dass du jede Art von Daten in eine Aufzählungsvariante einfügen kannst: Zeichenketten, numerische Typen, Strukturen usw. Du kannst sogar eine weitere Aufzählung einfügen! Außerdem sind Standardbibliothekstypen oft nicht viel komplizierter als das, was du dir vielleicht ausdenkst. Beachte, dass wir, obwohl die Standardbibliothek eine Definition für IpAddr enthält, konfliktfrei unsere eigene Definition erstellen und verwenden können, da wir die Definition der Standardbibliothek nicht in unseren Gültigkeitsbereich aufgenommen haben. Wir werden in Kapitel 7 mehr darauf eingehen, wie man Typen in den Gültigkeitsbereich aufnimmt.

Schauen wir uns ein weiteres Beispiel für eine Aufzählung in Codeblock 6-2 an: In dieser Aufzählung ist eine Vielzahl von Typen in ihren Varianten eingebettet.

#![allow(unused)]
fn main() {
enum Message {
    Quit,
    Move { x: i32, y: i32 },
    Write(String),
    ChangeColor(i32, i32, i32),
}
}

Codeblock 6-2: Eine Aufzählung Message, deren Varianten jeweils eine unterschiedliche Anzahl an Werttypen speichern

Diese Aufzählung hat vier Varianten mit unterschiedlichen Typen:

• Quit hat überhaupt keine Daten.
• Move hat benannte Felder wie eine Struktur.
• Write enthält einen einzelnen String.
• ChangeColor enthält drei i32-Werte.

Die Definition einer Aufzählung mit Varianten wie in Codeblock 6-2 ist ähnlich zur Definition verschiedener Arten von Strukturdefinitionen, außer dass die Aufzählung nicht das Schlüsselwort struct verwendet und alle Varianten unter dem Typ Message zusammengefasst sind. Die folgenden Strukturen könnten die gleichen Daten aufnehmen wie die vorhergehenden Aufzählungsvarianten:

#![allow(unused)]
fn main() {
struct QuitMessage; // leere Struktur
struct MoveMessage {
    x: i32,
    y: i32,
}
struct WriteMessage(String); // Tupelstruktur
struct ChangeColorMessage(i32, i32, i32); // Tupelstruktur
}

Aber wenn wir die verschiedenen Strukturen verwenden würden, die jeweils ein eigener Typ sind, könnten wir nicht so einfach eine Funktion definieren, die eine dieser Nachrichtenarten entgegennimmt, wie wir es mit der in Codeblock 6-2 definierten Aufzählung Message gemacht haben, bei der es sich um einen einzigen Typ handelt.

Es gibt noch eine weitere Ähnlichkeit zwischen Aufzählungen und Strukturen: So wie wir Methoden für Strukturen mit impl definieren können, können wir auch Methoden für Aufzählungen definieren. Hier ist eine Methode namens call, die wir für unsere Aufzählung Message definieren könnten:

fn main() {
    enum Message {
        Quit,
        Move { x: i32, y: i32 },
        Write(String),
        ChangeColor(i32, i32, i32),
    }

    impl Message {
        fn call(&self) {
            // Methodenrumpf
        }
    }

    let m = Message::Write(String::from("hallo"));
    m.call();
}

Der Methodenrumpf würde self benutzen, um den Wert zu erhalten, auf den wir die Methode aufgerufen haben. In diesem Beispiel haben wir eine Variable m erstellt, die den Wert Message::Write(String::from("hallo")) hat. Genau diesen Wert wird self im Rumpf der Methode call haben, wenn m.call() ausgeführt wird.

Sehen wir uns eine weitere Aufzählung in der Standardbibliothek an, die sehr verbreitet und hilfreich ist: Option

Die Aufzählung Option und ihre Vorteile gegenüber Nullwerten

Dieser Abschnitt befasst sich mit einer Fallstudie zu Option, einer weiteren Aufzählung, die von der Standardbibliothek definiert wird. Der Typ Option kodiert das sehr häufige Szenario, in dem ein Wert etwas oder nichts sein kann.

Wenn du zum Beispiel das erste Element einer nichtleeren Liste anforderst, erhältst du einen Wert. Wenn du das erste Element einer leeren Liste abfragst, erhältst du nichts. Im Sinne des Typsystems bedeutet das, dass der Compiler überprüfen kann, ob du alle Fälle behandelt hast, die du behandelt haben solltest. Diese Funktionalität kann Fehler vermeiden, die in anderen Programmiersprachen extrem häufig auftreten.

Bei der Entwicklung von Programmiersprachen wird oft überlegt, welche Funktionalität aufgenommen werden soll, aber auch die auszuschließende Funktionalität ist wichtig. Rust hat nicht die Funktionalität „null“, die es in vielen anderen Sprachen gibt. Null ist ein Wert, der bedeutet, dass kein Wert vorhanden ist. In Sprachen mit null können sich Variablen immer in einem von zwei Zuständen befinden: null oder nicht null.

In seinem Vortrag „Nullreferenzen: Der milliardenschwere Fehler“ von 2009 hat Tony Hoare, der Erfinder von null, folgendes gesagt:

Ich nenne es meinen milliardenschweren Fehler. Zu dieser Zeit entwarf ich das erste umfangreiche Typsystem für Referenzen in einer objektorientierten Sprache. Mein Ziel war es, sicherzustellen, dass jede Verwendung von Referenzen absolut sicher sein sollte, wobei die Überprüfung automatisch durch den Compiler durchgeführt wird. Aber ich konnte der Versuchung nicht widerstehen, eine Nullreferenz einzuführen, nur weil sie so einfach umzusetzen war. Dies hat zu unzähligen Fehlern, Schwachstellen und Systemabstürzen geführt, die in den letzten vierzig Jahren wahrscheinlich eine Milliarde Dollar Schmerz und Schaden verursacht haben.

Das Problem mit Nullwerten besteht darin, dass du einen Fehler erhältst, wenn du versuchst, einen Nullwert als Nicht-Nullwert zu verwenden. Da diese Null- oder Nicht-Null-Eigenschaft allgegenwärtig ist, ist es extrem einfach, einen derartigen Fehler zu machen.

Das Konzept, das die Null zum Ausdruck bringen will, ist jedoch nach wie vor nützlich: Null ist ein Wert, der aktuell ungültig ist oder aus irgendeinem Grund nicht vorhanden ist.

Das Problem liegt nicht wirklich im Konzept, sondern in der konkreten Umsetzung. Als solches hat Rust keine Nullen, aber es hat eine Aufzählung, die das Konzept des Vorhandenseins oder Nichtvorhandenseins eines Wertes abbilden kann. Diese Aufzählung heißt Option<T> und ist in der Standardbibliothek wie folgt definiert:

#![allow(unused)]
fn main() {
enum Option<T> {
    None,
    Some(T),
}
}

Die Aufzählung Option<T> ist so nützlich, dass sie sogar im Präludium enthalten ist; du musst sie nicht explizit in den Gültigkeitsbereich bringen. Ihre Varianten sind ebenfalls im Präludium enthalten: Du kannst Some und None direkt ohne Präfix Option:: verwenden. Die Aufzählung Option<T> ist dennoch nur eine normale Aufzählung, und Some(T) und None sind nur Varianten des Typs Option<T>.

Die Syntax <T> ist eine Funktionalität von Rust, über die wir noch nicht gesprochen haben. Es handelt sich um einen generischen Typparameter, auf den wir in Kapitel 10 näher eingehen werden. Für den Moment musst du nur wissen, dass <T> bedeutet, dass die Variante Some der Aufzählung Option einen Wert eines beliebigen Typs enthalten kann und dass jeder konkrete Typ, der anstelle von T verwendet wird, den Gesamttyp Option<T> zu einem anderen Typ macht. Hier sind einige Beispiele für die Verwendung von Option-Werten zur Aufnahme von Zahlentypen und Zeichenkettentypen:

#![allow(unused)]
fn main() {
let some_number = Some(5);
let some_char = Some('e');

let absent_number: Option<i32> = None;
}

Der Typ von some_number ist Option<i32>. Der Typ von some_char ist Option<char>, was ein anderer Typ ist. Rust kann diese Typen ableiten, weil wir einen Wert innerhalb der Some-Variante angegeben haben. Für absent_number verlangt Rust den gesamten Typ Option zu annotieren: Der Compiler kann den Typ, den die entsprechende Some-Variante haben wird, nicht ableiten, wenn sie nur einen None-Wert enthält. Hier sagen wir Rust, dass absent_number vom Typ Option<i32> sein soll.

Wenn wir einen Wert Some haben, wissen wir, dass ein Wert vorhanden ist und der Wert innerhalb von Some gehalten wird. Wenn wir einen Wert None haben, bedeutet das in gewisser Weise dasselbe wie Null: Wir haben keinen gültigen Wert. Warum ist nun besser Option<T> anstelle von Null zu verwenden?

Kurz gesagt, weil Option<T> und T (wobei T ein beliebiger Typ sein kann) unterschiedliche Typen sind, erlaubt es der Compiler nicht Option<T> so zu verwenden als wäre es definitiv ein gültiger Wert. Beispielsweise lässt sich dieser Code nicht kompilieren, weil er versucht, ein i8 mit einem Option<i8> zu addieren:

#![allow(unused)]
fn main() {
let x: i8 = 5;
let y: Option<i8> = Some(5);

let sum = x + y;
}

Wenn wir diesen Code ausführen, erhalten wir eine Fehlermeldung wie diese:

$ cargo run
   Compiling enums v0.1.0 (file:///projects/enums)
error[E0277]: cannot add `Option<i8>` to `i8`
 --> src/main.rs:5:17
  |
5 |     let sum = x + y;
  |                 ^ no implementation for `i8 + Option<i8>`
  |
  = help: the trait `Add<Option<i8>>` is not implemented for `i8`
  = help: the following other types implement trait `Add<Rhs>`:
            <i8 as Add>
            <i8 as Add<&i8>>
            <&'a i8 as Add<i8>>
            <&i8 as Add<&i8>>

For more information about this error, try `rustc --explain E0277`.
error: could not compile `enums` (bin "enums") due to 1 previous error

Stark! Tatsächlich bedeutet diese Fehlermeldung, dass Rust nicht versteht, wie man ein i8 und eine Option<i8> addiert, da es sich um unterschiedliche Typen handelt. Wenn wir einen Wert eines Typs wie i8 in Rust haben, stellt der Compiler sicher, dass wir immer einen gültigen Wert haben. Wir können getrost fortfahren, ohne vor der Verwendung dieses Wertes auf Null prüfen zu müssen. Nur wenn wir eine Option<i8> (oder einen anderen Werttyp) haben, müssen wir befürchten, dass wir möglicherweise keinen Wert haben, und der Compiler wird sicherstellen, dass wir diesen Fall behandeln, bevor wir den Wert verwenden.

Mit anderen Worten musst du eine Option<T> in ein T konvertieren, bevor du T-Operationen darauf durchführen kannst. Im Allgemeinen hilft dies, eines der häufigsten Probleme mit Null abzufangen: Anzunehmen, dass etwas nicht null ist, obwohl es tatsächlich null ist.

Durch Vermeiden des Risikos, fälschlicherweise einen Nicht-Null-Wert anzunehmen, gewinnst du mehr Vertrauen in deinen Code. Um einen Wert zu haben, der möglicherweise null sein kann, musst du dich explizit dafür entscheiden, indem du als Typ Option<T> verwendest. Wenn du dann diesen Wert verwendest, musst du den Fall null explizit behandeln. Überall dort, wo ein Wert nicht den Typ Option<T> hat, kannst du sicher sein, dass der Wert nicht null ist. Dies war eine bewusste Konstruktionsentscheidung bei Rust, um die Verbreitung von Null einzuschränken und die Sicherheit von Rust-Code zu erhöhen.

Wie erhältst du nun den T-Wert aus einer Variante Some, wenn du einen Wert vom Typ Option<T> hast? Die Aufzählung Option<T> enthält eine große Anzahl von Methoden, die in einer Vielzahl von Situationen nützlich sind; mehr dazu findest du in der Dokumentation. Sich mit den Methoden von Option<T> vertraut zu machen, wird dir auf deiner Reise mit Rust äußerst nützlich sein.

Um einen Option<T>-Wert zu verwenden, benötigst du im Allgemeinen Code, der jede Variante behandelt. Du möchtest einen Code, der nur läuft, wenn du einen Wert Some(T) hast, und dieser Code darf das innere T benutzen. Du möchtest, dass ein anderer Code ausgeführt wird, wenn du einen Wert None hast, und dieser Code hat keinen T-Wert. Der Ausdruck match ist ein Kontrollflusskonstrukt, das genau dies tut, wenn es mit Aufzählungen verwendet wird: Es führt unterschiedlichen Code aus, je nachdem, welche Variante der Aufzählung es hat, und dieser Code kann die Daten innerhalb des passenden Wertes verwenden.

Das Kontrollflusskonstrukt match

Rust verfügt über ein extrem leistungsfähiges Kontrollflusskonstrukt namens match, der es dir ermöglicht, einen Wert mit einer Reihe von Mustern abzugleichen und dann Code zum jeweils passenden Muster auszuführen. Muster können sich aus Literalen, Variablennamen, Platzhaltern und vielen anderen Dingen zusammensetzen. Kapitel 18 befasst sich mit all den verschiedenen Musterarten und wie sie funktionieren. Die Mächtigkeit von match kommt von der Ausdruckskraft der Muster und der Tatsache, dass der Compiler sicherstellt, dass alle möglichen Fälle behandelt werden.

Stelle dir einen match-Ausdruck wie eine Münzsortiermaschine vor: Die Münzen rutschen eine Bahn mit unterschiedlich großen Löchern entlang, und jede Münze fällt durch das erste Loch, in das sie hineinpasst. Auf die gleiche Weise durchlaufen die Werte die Muster in einem match-Ausdruck und beim ersten „passenden“ Muster fällt der Wert in den zugehörigen Codeblock, der ausgeführt werden soll.

Apropos Münzen, nehmen wir sie als Beispiel für die Verwendung von match! Wir können eine Funktion schreiben, die eine unbekannte US-Münze nimmt und, ähnlich wie die Zählmaschine, bestimmt, um welche Münze es sich handelt und ihren Wert in Cent zurückgibt, wie in Codeblock 6-3 gezeigt.

#![allow(unused)]
fn main() {
enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter,
}

fn value_in_cents(coin: Coin) -> u8 {
    match coin {
        Coin::Penny => 1,
        Coin::Nickel => 5,
        Coin::Dime => 10,
        Coin::Quarter => 25,
    }
}
}

Codeblock 6-3: Eine Aufzählung und ein match-Ausdruck, der die Varianten der Aufzählung als Muster hat

Lass uns den match-Ausdruck in der Funktion value_in_cents aufschlüsseln. Zuerst geben wir das Schlüsselwort match an, gefolgt von einem Ausdruck, der in diesem Fall der Wert coin ist. Dies scheint einem bedingten Ausdruck sehr ähnlich zu sein, der bei if verwendet wird, aber es gibt einen großen Unterschied: Bei if muss die Bedingung einen booleschen Wert ergeben, aber hier kann ein beliebiger Typ zurückgegeben werden. Der Typ von coin ist in diesem Beispiel die Aufzählung Coin, die wir in der ersten Zeile definiert haben.

Als nächstes kommen die match-Zweige. Ein Zweig hat zwei Teile: Ein Muster und etwas Code. Der erste Zweig hat als Muster den Wert Coin::Penny, dann den Operator =>, der das Muster und den auszuführenden Code trennt. Der Code ist in diesem Fall nur der Wert 1. Jeder Zweig wird durch ein Komma vom nächsten getrennt.

Wenn der match-Ausdruck ausgeführt wird, gleicht er den Ergebniswert mit dem Muster jedes Zweigs ab, und zwar der Reihe nach. Wenn ein Muster zum Wert passt, wird der zu diesem Muster gehörende Code ausgeführt. Wenn das Muster nicht zum Wert passt, wird die Ausführung beim nächsten Zweig fortgesetzt, ähnlich wie bei einer Münzsortiermaschine. Wir können so viele Zweige haben, wie wir brauchen: In Codeblock 6-3 hat unser match-Ausdruck vier Zweige.

Der zu jedem Zweig gehörende Code ist ein Ausdruck, und der Ergebniswert des Ausdrucks im zugehörenden Zweig ist der Wert, der für den gesamten match-Ausdruck zurückgegeben wird.

Wir verwenden üblicherweise keine geschweiften Klammern, wenn der Zweig-Code kurz ist, so wie in Codeblock 6-3, wo jeder Zweig nur einen Wert zurückgibt. Wenn du mehrere Codezeilen in einem Zweig ausführen möchtest, musst du geschweifte Klammern verwenden, und das Komma nach dem Zweig ist dann optional. Zum Beispiel gibt der folgende Code jedes Mal „Glückspfennig!“ aus, wenn die Methode mit Coin::Penny aufgerufen wird, er gibt aber immer noch den letzten Wert 1 des Blocks zurück:

#![allow(unused)]
fn main() {
enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter,
}

fn value_in_cents(coin: Coin) -> u8 {
    match coin {
        Coin::Penny => {
            println!("Glückspfennig!");
            1
        }
        Coin::Nickel => 5,
        Coin::Dime => 10,
        Coin::Quarter => 25,
    }
}
}

Muster, die Werte binden

Ein weitere nützliche Funktionalität von match-Zweigen ist, dass sie Teile der Werte binden können, die dem Muster entsprechen. Auf diese Weise können wir Werte aus Aufzählungsvarianten extrahieren.

Lass uns als Beispiel eine unserer Aufzählungsvarianten so ändern, dass sie Daten enthält. Von 1999 bis 2008 prägten die Vereinigten Staaten 25-Cent-Münzen mit unterschiedlichem Aussehen auf einer Seite für jeden der 50 Staaten. Keine andere Münze hatte ein Staaten-spezifisches Aussehen, sodass nur 25-Cent-Münzen diese zusätzliche Eigenschaft haben. Wir können diese Information in unserer Aufzählung unterbringen, indem wir die Variante Quarter so ändern, dass sie einen UsState-Wert enthält, wie in Codeblock 6-4 umgesetzt.

#![allow(unused)]
fn main() {
enum UsState {
    Alabama,
    Alaska,
    // --abschneiden--
}

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter(UsState),
}
}

Codeblock 6-4: Aufzählung Coin, bei der die Variante Quarter zusätzlich einen UsState-Wert enthält

Stellen wir uns vor, dass ein Freund versucht, 25-Cent-Münzen aller 50 Staaten zu sammeln. Während wir unser Kleingeld nach Münzsorten sortieren, geben wir auch den Namen des Staates der 25-Cent-Münze aus, sodass es unser Freund in seine Sammlung aufnehmen kann, falls er es nicht hat. Im match-Ausdruck für diesen Code fügen wir zum Muster der Variante Coin::Quarter eine Variable state hinzu. Wenn der Zweig für Coin::Quarter passt, wird die Variable state an den Wert der Eigenschaft der 25-Cent-Münze gebunden. Dann können wir state im Code für diesen Zweig etwa so verwenden:

#[derive(Debug)] // um den Staat mit println! ausgeben zu können
enum UsState {
    Alabama,
    Alaska,
    // --abschneiden--
}

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter(UsState),
}

fn value_in_cents(coin: Coin) -> u8 {
    match coin {
        Coin::Penny => 1,
        Coin::Nickel => 5,
        Coin::Dime => 10,
        Coin::Quarter(state) => {
            println!("25-Cent-Münze aus {:?}!", state);
            25
        }
    }
}

fn main() {
    value_in_cents(Coin::Quarter(UsState::Alaska));
}

Wenn wir value_in_cents(Coin::Quarter(UsState::Alaska)) aufrufen würden, hätte coin den Wert Coin::Quarter(UsState::Alaska). Gleichen wir den Wert mit jedem der match-Zweige ab, passt keiner von ihnen, bis wir Coin::Quarter(state) erreichen. An diesem Punkt wird state an den Wert UsState::Alaska gebunden. Wir können dann diese Bindung im println!-Ausdruck verwenden und so den inneren Zustandswert aus der Coin-Aufzählungsvariante für Quarter herausholen.

Abgleich mit Option<T>

Im vorigen Abschnitt wollten wir den inneren T-Wert aus dem Fall Some herausholen, als wir Option<T> verwendet haben. Wir können Option<T> ebenso mit match handhaben, wie wir es mit der Aufzählung Coin getan haben! Statt Münzen zu vergleichen, werden wir die Varianten von Option<T> vergleichen, aber die Art und Weise, wie der match-Ausdruck funktioniert, bleibt die gleiche.

Nehmen wir an, wir wollen eine Funktion schreiben, die eine Option<i32> nimmt und, falls ein Wert darin enthalten ist, zu diesem Wert 1 addiert. Wenn darin kein Wert enthalten ist, soll die Funktion den Wert None zurückgeben und nicht versuchen, irgendwelche Operationen durchzuführen.

Diese Funktion ist dank match sehr einfach zu schreiben und wird wie in Codeblock 6-5 aussehen.

#![allow(unused)]
fn main() {
fn plus_one(x: Option<i32>) -> Option<i32> {
    match x {
        None => None,
        Some(i) => Some(i + 1),
    }
}

let five = Some(5);
let six = plus_one(five);
let none = plus_one(None);
}

Codeblock 6-5: Eine Funktion, die einen match-Ausdruck auf einer Option<i32> verwendet

Lass uns die erste Ausführung von plus_one näher betrachten. Wenn wir plus_one(five) aufrufen, wird die Variable x im Rumpf von plus_one den Wert Some(5) haben. Dann vergleichen wir das mit jedem match-Zweig:

None => None,

Der Wert Some(5) passt nicht zum Muster None, also fahren wir mit dem nächsten Zweig fort:

Some(i) => Some(i + 1),

Passt Some(5) zu Some(i)? Das tut es! Wir haben die gleiche Variante. i bindet den in Some enthaltenen Wert, sodass i den Wert 5 annimmt. Dann wird der Code im match-Zweig ausgeführt, also fügen wir 1 zum Wert von i hinzu und erzeugen einen neuen Some-Wert mit der Summe 6 darin.

Betrachten wir nun den zweiten Aufruf von plus_one in Codeblock 6-5, wo x den Wert None hat. Wir betreten den match-Block und vergleichen mit dem ersten Zweig:

None => None,

Er passt! Es gibt keinen Wert zum Hinzufügen, also stoppt das Programm und gibt den Wert None auf der rechten Seite von => zurück. Da der erste Zweig passt, werden keine anderen Zweige abgeglichen.

Die Kombination von match und Aufzählungen ist in vielen Situationen nützlich. Du wirst dieses Muster häufig in Rust-Code sehen: match mit einer Aufzählung, eine Variable an die darin enthaltenen Daten binden und dann dazugehörenden Code ausführen. Am Anfang ist es etwas knifflig, aber wenn man sich erst einmal daran gewöhnt hat, wird man sich wünschen, es in allen Sprachen zu haben. Es ist durchweg ein beliebtes Werkzeug.

Abgleiche sind vollständig

Es gibt noch einen weiteren Aspekt von match, den wir besprechen müssen: Die Muster der Zweige müssen alle Möglichkeiten abdecken. Betrachte folgende Version unserer Funktion plus_one, die einen Fehler hat und sich nicht kompilieren lässt:

#![allow(unused)]
fn main() {
fn plus_one(x: Option<i32>) -> Option<i32> {
    match x {
        Some(i) => Some(i + 1),
    }
}

let five = Some(5);
let six = plus_one(five);
let none = plus_one(None);
}

Wir haben den Fall None nicht behandelt, daher wird dieser Code einen Fehler verursachen. Glücklicherweise ist es ein Fehler, von dem Rust weiß, wie er zu lösen ist. Wenn wir versuchen, diesen Code zu kompilieren, werden wir diese Fehlermeldung bekommen:

$ cargo run
   Compiling enums v0.1.0 (file:///projects/enums)
error[E0004]: non-exhaustive patterns: `None` not covered
 --> src/main.rs:3:15
  |
3 |         match x {
  |               ^ pattern `None` not covered
  |
note: `Option<i32>` defined here
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb/library/core/src/option.rs:570:1
 ::: /rustc/07dca489ac2d933c78d3c5158e3f43beefeb/library/core/src/option.rs:574:5
  |
  = note: not covered
  = note: the matched value is of type `Option<i32>`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
  |
4 ~             Some(i) => Some(i + 1),
5 ~             None => todo!(),
  |

For more information about this error, try `rustc --explain E0004`.
error: could not compile `enums` (bin "enums") due to 1 previous error

Rust weiß, dass wir nicht alle möglichen Fälle abgedeckt haben, und es weiß sogar, welches Muster wir vergessen haben! Abgleiche in Rust sind vollständig: Wir müssen jede letzte Möglichkeit ausschöpfen, damit der Code gültig ist! Speziell im Fall Option<T> schützt uns Rust davor, den Fall None zu übersehen, und davon auszugehen, dass wir einen Wert haben, obwohl vielleicht null vorliegt, und macht so den zuvor besprochenen Milliardenfehler unmöglich.

Auffangmuster und der Platzhalter _

Mit Aufzählungen können wir auch spezielle Aktionen für ausgewählte Werte durchführen und für alle anderen Werte eine Standardaktion. Stell dir vor, wir implementieren ein Spiel, bei dem ein Spieler bei einem Würfelwurf von 3 einen schicken Hut bekommt anstatt sich zu bewegen. Wenn du eine 7 würfelst, verliert dein Spieler einen schicken Hut. Bei allen anderen Werten zieht der Spieler die entsprechende Anzahl an Feldern auf dem Spielfeld. Hier ist ein match, das diese Logik implementiert, wobei das Ergebnis des Würfelwurfs anstelle eines Zufallswerts fest kodiert ist, und alle weitere Logik wird durch Funktionen ohne Rumpf dargestellt, da die tatsächliche Implementierung für dieses Beispiel den Rahmen sprengen würde:

#![allow(unused)]
fn main() {
let dice_roll = 9;
match dice_roll {
    3 => add_fancy_hat(),
    7 => remove_fancy_hat(),
    other => move_player(other),
}

fn add_fancy_hat() {}
fn remove_fancy_hat() {}
fn move_player(num_spaces: u8) {}
}

Bei den ersten beiden Zweigen sind die Muster die literalen Werte 3 und 7. Beim letzten Zweig, der alle anderen möglichen Werte abdeckt, ist das Muster die Variable die wir als other bezeichnet haben. Der Code, der für den other-Zweig läuft, verwendet die Variable, indem er sie an die Funktion move_player übergibt.

Dieser Code lässt sich kompilieren, auch wenn wir nicht alle möglichen Werte aufgelistet haben, die ein u8 haben kann, weil das letzte Muster zu allen nicht explizit aufgeführten Werte passt. Dieses Auffangmuster (catch-all pattern) erfüllt die Anforderung, dass match vollständig sein muss. Beachte, dass wir den Auffangzweig an letzter Stelle angeben müssen, da die Muster der Reihe nach ausgewertet werden. Wenn wir den Auffangzweig früher einfügen würden, würden die anderen Zweige nie ausgeführt werden, also warnt uns Rust, wenn wir Zweige nach einem Auffangzweig hinzufügen!

Rust hat auch ein Muster, das wir verwenden können, wenn wir einen Auffangzweig wollen, aber den Wert im Auffangmuster nicht verwenden wollen: _ ist ein spezielles Muster, das zu jedem Wert passt und nicht an diesen Wert bindet. Dies sagt Rust, dass wir den Wert nicht verwenden werden, damit Rust uns nicht vor einer unbenutzten Variable warnt.

Ändern wir die Spielregeln: Wenn du jetzt etwas anderes als eine 3 oder eine 7 würfelst, musst du erneut würfeln. Wir brauchen den Auffangwert nicht mehr zu verwenden, also können wir unseren Code so ändern, dass wir _ anstelle der Variable namens other verwenden:

#![allow(unused)]
fn main() {
let dice_roll = 9;
match dice_roll {
    3 => add_fancy_hat(),
    7 => remove_fancy_hat(),
    _ => reroll(),
}

fn add_fancy_hat() {}
fn remove_fancy_hat() {}
fn reroll() {}
}

Dieses Beispiel erfüllt auch die Bedingung der Vollständigkeit, weil wir ausdrücklich alle anderen Werte im letzten Zweig ignorieren; wir haben nichts vergessen.

Zum Schluss ändern wir die Spielregeln noch einmal, sodass bei einem Zug nichts anderes passiert, wenn etwas anderes als eine 3 oder eine 7 gewürfelt wird. Wir können das ausdrücken, indem wir den Einheitswert (den leeren Tupel-Typ, den wir im Abschnitt „Der Tupel-Typ“ erwähnt haben) als Code im _-Zweig angeben:

#![allow(unused)]
fn main() {
let dice_roll = 9;
match dice_roll {
    3 => add_fancy_hat(),
    7 => remove_fancy_hat(),
    _ => (),
}

fn add_fancy_hat() {}
fn remove_fancy_hat() {}
}

Hier teilen wir Rust explizit mit, dass wir keinen anderen Wert verwenden werden, der nicht mit einem Muster in einem früheren Zweig übereinstimmt, und dass wir in diesem Fall keinen Code ausführen wollen.

Weitere Informationen zu Mustern und Abgleich findest du in Kapitel 18. Für den Moment machen wir mit der if let-Syntax weiter, die in Situationen nützlich sein kann, in denen der match-Ausdruck etwas wortreich ist.

Prägnanter Kontrollfluss mit if let

Mit der Syntax if let kannst du if und let in einer weniger wortreichen Weise kombinieren, um mit Werten umzugehen, die einem Muster entsprechen, während der Rest ignoriert wird. Betrachte das Programm in Codeblock 6-6, das auf einen Option<u8>-Wert in der Variable config_max passt, aber nur dann Code ausführen soll, wenn der Wert die Some-Variante ist.

#![allow(unused)]
fn main() {
let config_max = Some(3u8);
match config_max {
    Some(max) => println!("Das Maximum ist mit {} konfiguriert", max),
    _ => (),
}
}

Codeblock 6-6: Ein match-Ausdruck, der nur dann Code ausführt, wenn der Wert Some ist

Wenn der Wert Some ist, geben wir den Wert in der Variante Some aus, indem wir den Wert an die Variable max im Muster binden. Wir wollen nichts mit dem Wert None machen. Um den Ausdruck match zu erfüllen, müssen wir nach der Verarbeitung nur einer Variante _ => () hinzufügen, was lästiger Codeballast ist.

Stattdessen könnten wir dies in kürzerer Form schreiben, indem wir if let verwenden. Der folgende Code verhält sich genauso wie der match-Ausdruck in Codeblock 6-6:

#![allow(unused)]
fn main() {
let config_max = Some(3u8);
if let Some(max) = config_max {
    println!("Das Maximum ist mit {} konfiguriert", max);
}
}

Die Syntax if let nimmt ein Muster und einen Ausdruck, getrennt durch ein Gleichheitszeichen. Sie funktioniert auf gleiche Weise wie bei match, wo der Ausdruck hinter match angegeben wird und das Muster der erste Zweig ist. In diesem Fall ist das Muster Some(max) und das max ist an den Wert innerhalb von Some gebunden. Wir können dann max im Rumpf des if let-Blocks auf die gleiche Weise verwenden, wie max im entsprechenden match-Zweig. Der Code im if let-Block wird nicht ausgeführt, wenn der Wert nicht zum Muster passt.

Die Verwendung von if let bedeutet weniger Tipparbeit, weniger Einrückung und weniger Codeanteil. Du verlierst jedoch die Prüfung auf Vollständigkeit, die match erzwingt. Die Wahl zwischen match und if let hängt davon ab, was du in der speziellen Situation machst, und davon, ob ein Gewinn an Prägnanz ein angemessener Kompromiss für den Verlust einer Prüfung auf Vollständigkeit ist.

Anders gesagt kannst du dir if let als syntaktischen Zucker für einen match-Ausdruck vorstellen, der Code nur bei Übereinstimmung mit einem Muster ausführt und alle anderen Werte ignoriert.

Wir können ein else an ein if let anhängen. Der Code-Block, der zum else gehört, ist der gleiche wie der Code-Block, der zum _-Zweig im match-Ausdruck gehören würde. Erinnere dich an die Aufzählung Coin in Codeblock 6-4, wo die Variante Quarter auch einen UsState-Wert enthielt. Wenn wir alle Nicht-25-Cent-Münzen zählen wollten, während wir die Eigenschaft der 25-Cent-Münzen ausgeben, könnten wir das mit einem match-Ausdruck wie diesem tun:

#[derive(Debug)]
enum UsState {
    Alabama,
    Alaska,
    // --abschneiden--
}

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter(UsState),
}

fn main() {
    let coin = Coin::Penny;
    let mut count = 0;
    match coin {
        Coin::Quarter(state) => println!("25-Cent-Münze aus {:?}!", state),
        _ => count += 1,
    }
}

Oder wir könnten einen Ausdruck mit if let und else wie diesen verwenden:

#[derive(Debug)]
enum UsState {
    Alabama,
    Alaska,
    // --abschneiden--
}

enum Coin {
    Penny,
    Nickel,
    Dime,
    Quarter(UsState),
}

fn main() {
    let coin = Coin::Penny;
    let mut count = 0;
    if let Coin::Quarter(state) = coin {
        println!("25-Cent-Münze aus {:?}!", state);
    } else {
        count += 1;
    }
}

Wenn du eine Situation hast, in der dein Programm über eine Logik verfügt, die mit einem match-Ausdruck zu wortreich auszudrücken wäre, denke daran, dass if let ebenfalls in deinem Rust-Werkzeugkasten enthalten ist.

Zusammenfassung

Wir haben uns damit befasst, wie man Aufzählungen verwendet, um benutzerdefinierte Typen zu erstellen, die zu einem Satz von Aufzählungswerten gehören können. Wir haben gezeigt, wie der Typ Option<T> der Standardbibliothek dir dabei hilft, das Typsystem zu verwenden, um Fehler zu vermeiden. Wenn Aufzählungswerte Daten enthalten, kannst du diese Werte mit match oder if let extrahieren und verwenden, je nachdem, wie viele Fälle du behandeln musst.

Deine Rust-Programme können nun Konzepte in deiner Domäne mit Hilfe von Strukturen und Aufzählungen ausdrücken. Das Erstellen benutzerdefinierter Typen zur Verwendung in deiner API gewährleistet Typsicherheit: Der Compiler wird sicherstellen, dass deine Funktionen nur Werte jenes Typs erhalten, den die Funktion erwartet.

Um deinen Nutzern eine gut organisierte API zur Verfügung zu stellen, die einfach zu benutzen ist und nur genau das offenbart, was deine Nutzer benötigen, wenden wir uns nun den Modulen von Rust zu.

Wachsende Projekte verwalten mit Paketen (packages), Kisten (crates) und Modulen

Wenn du große Programme schreibst, wird die Organisation deines Codes immer wichtiger. Durch die Gruppierung verwandter Funktionen und die Trennung von Code mit unterschiedlichen Funktionalitäten wird klar, wo der Code zu finden ist, der eine bestimmte Funktionalität implementiert, und an welcher Stelle die Funktionalität eines Merkmals zu ändern ist.

Die Programme, die wir bisher geschrieben haben, waren in einem Modul in einer Datei. Wenn ein Projekt wächst, solltest du den Code organisieren, indem du ihn in mehrere Module und dann in mehrere Dateien aufteilst. Ein Paket (package) kann mehrere Binär-Kisten (binary crates) und optional eine Bibliotheks-Kiste (library crate) enthalten. Wenn ein Paket wächst, kannst du Teile in separate Kisten extrahieren, die zu externen Abhängigkeiten werden. Dieses Kapitel behandelt all diese Techniken. Für sehr große Projekte aus einer Reihe von zusammenhängenden Paketen, die sich gemeinsam weiterentwickeln, stellt Cargo Arbeitsbereiche zur Verfügung, die wir im Abschnitt „Cargo-Arbeitsbereiche“ in Kapitel 14 behandeln werden.

Wir werden auch die Kapselung von Implementierungsdetails besprechen, wodurch du Code auf einer höheren Ebene wiederverwenden kannst: Sobald du eine Operation implementiert hast, kann anderer Code diesen Code über die öffentliche Schnittstelle des Codes aufrufen, ohne wissen zu müssen, wie die Implementierung funktioniert. Die Art und Weise, wie du Code schreibst, definiert, welche Teile für anderen Code öffentlich sind und welche Teile private Implementierungsdetails sind, deren Änderung du dir vorbehältst. Dies ist eine weitere Möglichkeit, die Menge der Details, die man im Kopf behalten muss, zu begrenzen.

Ein verwandtes Konzept ist der Gültigkeitsbereich (scope): Der verschachtelte Kontext, in dem Code geschrieben wird, hat eine Reihe von Namen, die als „im Gültigkeitsbereich“ (in scope) definiert sind. Beim Lesen, Schreiben und Kompilieren von Code müssen Programmierer und Compiler wissen, ob sich ein bestimmter Name an einer bestimmten Stelle auf eine Variable, Funktion, Struktur (struct), Aufzählung (enum), Modul, Konstante oder ein anderes Element bezieht und was dieses Element bedeutet. Du kannst Gültigkeitsbereiche erstellen und verändern, welche Namen in oder außerhalb des Gültigkeitsbereichs liegen. Du kannst nicht zwei Elemente mit gleichem Namen im selben Gültigkeitsbereich haben; es sind Werkzeuge zur Lösung von Namenskonflikten vorhanden.

Rust verfügt über eine Reihe von Funktionalitäten, mit denen du die Organisation deines Codes verwalten kannst, z.B. welche Details offengelegt werden, welche Details privat sind und welche Namen im jeweiligen Gültigkeitsbereich deines Programms sind. Zu diesen Funktionalitäten, die manchmal kollektiv als Modulsystem bezeichnet werden, gehören:

• Pakete (packages): Eine Cargo-Funktionalität, mit der du Kisten bauen, testen und gemeinsam nutzen kannst.
• Kisten (crates): Ein Baum von Modulen, der eine Bibliothek oder ein ausführbares Programm erzeugt.
• Module und use: Ermöglicht dir, die Organisation, den Gültigkeitsbereich und den Datenschutz von Pfaden zu steuern.
• Pfade: Eine Möglichkeit, ein Element zu benennen, z.B. eine Struktur, eine Funktion oder ein Modul.

In diesem Kapitel gehen wir auf all diese Funktionalitäten ein, besprechen, wie sie zusammenwirken, und erklären, wie sie zur Verwaltung der Gültigkeitsbereiche eingesetzt werden können. Am Ende solltest du ein solides Verständnis des Modulsystems haben und in der Lage sein, mit den Gültigkeitsbereichen wie ein Profi zu arbeiten!

Pakete (packages) und Kisten (crates)

Die ersten Teile des Modulsystems, die wir behandeln werden, sind Pakete und Kisten.

Eine Kiste ist die kleinste Menge an Code, die der Rust-Compiler zu einem bestimmten Zeitpunkt berücksichtigt. Selbst wenn du rustc anstelle von cargo ausführst und eine einzelne Quellcodedatei übergibst (wie wir es bereits im Abschnitt „Schreiben und Ausführen eines Rust-Programms“ in Kapitel 1 getan haben), betrachtet der Compiler diese Datei als eine Kiste. Kisten können Module enthalten, und die Module können in anderen Dateien definiert sein, die mit der Kiste kompiliert werden, wie wir in den nächsten Abschnitten sehen werden.

Es gibt zwei Arten von Kisten: Binäre Kisten und Bibliothekskisten. Binäre Kisten (binary crates) sind Programme, die du zu einer ausführbaren Datei kompilieren und starten kannst, z.B. ein Befehlszeilenprogramm oder einen Server. Jede muss eine Funktion namens main haben, die definiert, was passiert, wenn die ausführbare Datei läuft. Alle Kisten, die wir bisher erstellt haben, waren binäre Kisten.

Bibliothekskisten (library crates) haben keine main-Funktion und sie werden nicht zu einer ausführbaren Datei kompiliert. Stattdessen definieren sie Funktionalität, die für mehrere Projekte gemeinsam genutzt werden soll. Zum Beispiel bietet die Kiste rand, die wir in Kapitel 2 verwendet haben, Funktionalität, die Zufallszahlen erzeugt. Wenn Rust-Entwickler „Kiste“ sagen, meinen sie meistens „Bibliothekskiste“, und sie verwenden „Kiste“ austauschbar mit dem allgemeinen Programmierkonzept einer „Bibliothek“.

Die Kistenwurzel ist eine Quelldatei, von der der Rust-Compiler ausgeht und die das Wurzel-Modul deiner Kiste bildet (Module werden im Abschnitt „Mit Modulen den Kontrollumfang und Datenschutz steuern“ ausführlich erklärt).

Ein Paket ist ein Bündel von einer oder mehreren Kisten, die eine Reihe von Funktionalitäten bereitstellen. Ein Paket enthält eine Datei Cargo.toml, die beschreibt, wie diese Kisten zu bauen sind. Cargo ist eigentlich ein Paket, das die Binärkiste für das Kommandozeilenwerkzeug enthält, das du zum Erstellen deines Codes verwendet hast. Das Cargo-Paket enthält auch eine Bibliothekskiste, von der die binäre Kiste abhängt. Andere Projekte können von der Cargo-Bibliothekskiste abhängen, um die gleiche Logik wie das Cargo-Befehlszeilenwerkzeug zu verwenden.

Ein Paket kann beliebig viele Binärkisten enthalten, aber höchstens eine Bibliothekskiste. Ein Paket muss mindestens eine Kiste enthalten, unabhängig davon, ob es sich um eine Bibliothek oder eine binäre Kiste handelt.

Lass uns durchgehen, was passiert, wenn wir ein Paket erstellen. Zuerst geben wir den Befehl cargo new ein:

$ cargo new my-project
     Created binary (application) `my-project` package
$ ls my-project
Cargo.toml
src
$ ls my-project/src
main.rs

Nachdem wir cargo new ausgeführt haben, verwenden wir ls, um zu sehen, was Cargo erzeugt. Im Projektverzeichnis gibt es eine Datei Cargo.toml, die uns ein Paket gibt. Es gibt auch ein Verzeichnis src, das main.rs enthält. Öffne Cargo.toml in deinem Texteditor und beachte, dass src/main.rs nicht erwähnt wird. Cargo folgt der Konvention, dass src/main.rs die Kistenwurzel einer binären Kiste mit dem gleichen Namen wie das Paket ist. Ebenso weiß Cargo, dass, wenn das Paketverzeichnis src/lib.rs enthält, das Paket eine Bibliothekskiste mit dem gleichen Namen wie das Paket enthält, und src/lib.rs deren Kistenstamm ist. Cargo übergibt die Kistenwurzel-Dateien an rustc, um die Bibliothek oder Binärdatei zu bauen.

Hier haben wir ein Paket, das nur src/main.rs enthält, d.h. es enthält nur eine binäre Kiste mit dem Namen my-project. Wenn ein Paket src/main.rs und src/lib.rs enthält, hat es zwei Kisten: Eine binäre und eine Bibliothek, beide mit dem gleichen Namen wie das Paket. Ein Paket kann mehrere binäre Kisten haben, indem es Dateien im Verzeichnis src/bin ablegt: Jede Datei ist dann eine eigene binäre Kiste.

Mit Modulen den Kontrollumfang und Datenschutz steuern

In diesem Abschnitt werden wir über Module und andere Teile des Modulsystems sprechen, nämlich Pfade, die es dir erlauben, Elemente zu benennen; das Schlüsselwort use, das einen Pfad in den Gültigkeitsbereich bringt; und das Schlüsselwort pub, um Elemente öffentlich zu machen. Wir werden auch das Schlüsselwort as, externe Pakete und den Stern-Operator (glob operator) besprechen.

Zunächst werden wir mit einer Liste von Regeln beginnen, damit du bei der künftigen Organisation deines Codes leicht nachschlagen kannst. Dann werden wir jede der Regeln im Detail erklären.

Spickzettel für Module

Hier bieten wir eine Kurzreferenz darüber, wie Module, Pfade, das Schlüsselwort use und das Schlüsselwort pub im Compiler funktionieren und wie die meisten Entwickler ihren Code organisieren. Wir werden im Laufe dieses Kapitels Beispiele für jede dieser Regeln durchgehen, aber dies ist ein guter Ort, um sich daran zu erinnern, wie Module funktionieren.

• Beginne bei der Kistenwurzel (crate root): Beim Kompilieren einer Kiste sucht der Compiler zuerst in der Wurzeldatei der Kiste (normalerweise src/lib.rs für eine Bibliothekskiste oder src/main.rs für eine Binärkiste).
• Module deklarieren: In der Kisten-Stammdatei kannst du neue Module deklarieren; z.B. deklarierst du ein „Garten“-Modul mit mod garden;. Der Compiler wird an diesen Stellen nach dem Code des Moduls suchen:
  • In der Zeile direkt nach mod garden, in geschweiften Klammern anstelle des Semikolons
  • In der Datei src/garden.rs
  • In der Datei src/garden/mod.rs
• Submodule deklarieren: In jeder anderen Datei als der Kistenwurzel kannst du Untermodule deklarieren. Du kannst zum Beispiel mod vegetables; in src/garden.rs deklarieren. Der Compiler sucht den Code des Submoduls in dem Verzeichnis, das nach dem übergeordneten Modul benannt ist, an folgenden Stellen:
  • In der Zeile direkt nach mod vegetables, in geschweiften Klammern anstelle des Semikolons
  • In der Datei src/garden/vegetables.rs
  • In der Datei src/garden/vegetables/mod.rs
• Pfade zum Code in Modulen: Sobald ein Modul Teil deiner Kiste ist, kannst du auf den Code in diesem Modul von jedem anderen Ort in derselben Kiste aus referenzieren, solange die Datenschutzregeln dies zulassen, indem du den Pfad zum Code verwendest. Zum Beispiel würde ein Typ Asparagus (engl. Spargel) im Gartengemüse-Modul unter crate::garden::vegetables::Asparagus zu finden sein.
• Privat vs. öffentlich: Der Code innerhalb eines Moduls ist standardmäßig für seine übergeordneten Module nicht zugänglich. Um ein Modul öffentlich zu machen, deklariere es mit pub mod anstelle von mod. Um Elemente innerhalb eines öffentlichen Moduls ebenfalls öffentlich zu machen, verwende pub vor ihren Deklarationen.
• Das Schlüsselwort use: Innerhalb eines Gültigkeitsbereichs werden mit dem Schlüsselwort use Verknüpfungen zu Elementen erstellt, um die Wiederholung langer Pfade zu reduzieren. In jedem Gültigkeitsbereichs, der auf crate::garden::vegetables::Asparagus referenzieren kann, kann man eine Verknüpfung mit use crate::garden::vegetables::Asparagus erstellen und von da an braucht man nur noch Asparagus zu schreiben, um diesen Typ im Gültigkeitsbereich zu verwenden.

Hier erstellen wir eine binäre Kiste namens backyard (Hinterhof), die diese Regeln veranschaulicht. Das Verzeichnis der Kiste, ebenfalls backyard genannt, enthält diese Dateien und Verzeichnisse:

backyard
├── Cargo.lock
├── Cargo.toml
└── src
    ├── garden
    │   └── vegetables.rs
    ├── garden.rs
    └── main.rs

Die Stammdatei der Kiste ist in diesem Fall src/main.rs, und sie enthält:

Dateiname: src/main.rs

use crate::garden::vegetables::Asparagus;

pub mod garden;

fn main() {
    let plant = Asparagus {};
    println!("Ich baue {:?} an!", plant);
}

Die Zeile pub mod garden; weist den Compiler an, den Code einzubinden, den er in src/garden.rs findet, nämlich:

Dateiname: src/garden.rs

pub mod vegetables;

Hier bedeutet pub mod vegetables;, dass der Code in src/garden/vegetables.rs ebenfalls enthalten ist. Dieser Code ist:

#[derive(Debug)]
pub struct Asparagus {}

Lass uns nun auf die Einzelheiten dieser Regeln eingehen und sie in der Praxis demonstrieren!

Gruppierung von zugehörigem Code in Modulen

Module ermöglichen es uns, den Code innerhalb einer Kiste zu organisieren, damit er lesbar und leicht wiederverwendbar ist. Mit Modulen können wir auch den Datenschutz (privacy) von Elementen kontrollieren, da Code innerhalb eines Moduls standardmäßig privat ist. Private Elemente sind interne Implementierungsdetails, die nicht für die externe Nutzung zur Verfügung stehen. Wir können uns dafür entscheiden, Module und die darin enthaltenen Elemente öffentlich zu machen, damit externer Code sie verwenden und von ihnen abhängen kann.

Als Beispiel schreiben wir eine Bibliothekskiste, die die Funktionalität eines Restaurants bietet. Wir werden die Signaturen der Funktionen definieren, aber ihre Rümpfe leer lassen, um uns auf die Organisation des Codes zu konzentrieren und nicht auf die Implementierung eines Restaurants.

Im Gaststättengewerbe werden einige Teile eines Restaurants als Vorderseite des Hauses und andere als Hinterseite des Hauses bezeichnet. Auf der Vorderseite des Hauses sind die Kunden; hier setzen Gastgeber ihre Kunden hin, Kellner nehmen Bestellungen auf und rechnen ab und Barkeeper machen die Getränke. Auf der Hinterseite des Hauses arbeiten die Küchenchefs und Köche in der Küche, Geschirrspüler waschen ab und Manager erledigen Verwaltungsarbeiten.

Um unsere Kiste auf diese Weise zu strukturieren, können wir ihre Funktionen in verschachtelten Modulen organisieren. Erstelle eine neue Bibliothek namens restaurant, indem du cargo new --lib restaurant ausführst; gib dann den Code in Codeblock 7-1 in src/lib.rs ein, um einige Module und Funktionssignaturen zu definieren. Hier ist der vordere Teil des Hauses:

Dateiname: src/lib.rs

mod front_of_house {
    mod hosting {
        fn add_to_waitlist() {}

        fn seat_at_table() {}
    }

    mod serving {
        fn take_order() {}

        fn serve_order() {}

        fn take_payment() {}
    }
}

Codeblock 7-1: Ein Modul front_of_house, das andere Module enthält, die dann Funktionen enthalten

Wir definieren ein Modul mit dem Schlüsselwort mod, gefolgt vom Namen des Moduls (in diesem Fall front_of_house). Der Rumpf des Moduls steht dann in geschweiften Klammern. Innerhalb von Modulen können wir andere Module platzieren, wie in diesem Fall mit den Modulen hosting und serving. Module können auch Definitionen für andere Elemente enthalten, wie Strukturen, Aufzählungen, Konstanten, Merkmalen und – wie in Codeblock 7-1 – Funktionen.

Durch die Verwendung von Modulen können wir verwandte Definitionen gruppieren und angeben, warum sie verwandt sind. Programmierer, die diesen Code verwenden, können anhand der Gruppen durch den Code navigieren, anstatt alle Definitionen lesen zu müssen, und finden so leichter die für sie relevanten Definitionen. Programmierer, die diesem Code neue Funktionalität hinzufügen, wissen, wo sie den Code platzieren müssen, damit das Programm übersichtlich bleibt.

Vorhin haben wir erwähnt, dass src/main.rs und src/lib.rs als Kistenwurzel bezeichnet werden. Der Grund für ihren Namen ist, dass der Inhalt dieser beiden Dateien ein Modul namens crate an der Wurzel der Modulstruktur der Kiste bilden, die als Modulbaum bekannt ist.

Codeblock 7-2 zeigt den Modulbaum für die Struktur in Codeblock 7-1.

crate
 └── front_of_house
     ├── hosting
     │   ├── add_to_waitlist
     │   └── seat_at_table
     └── serving
         ├── take_order
         ├── serve_order
         └── take_payment

Codeblock 7-2: Modulbaum für den Code in Codeblock 7-1

Dieser Baum zeigt, wie einige der Module ineinander verschachtelt sind; z.B. ist hosting innerhalb von front_of_house. Der Baum zeigt auch, dass einige Module Geschwister voneinander sind, was bedeutet, dass sie im selben Modul definiert sind; hosting und serving sind Geschwister, die innerhalb von front_of_house definiert sind. Wenn Modul A innerhalb von Modul B enthalten ist, sagen wir, dass Modul A das Kind (child) von Modul B ist und dass Modul B der Elternteil (parent) von Modul A ist. Beachte, dass der gesamte Modulbaum als Wurzel das implizite Modul namens crate hat.

Der Modulbaum könnte dich an den Verzeichnisbaum des Dateisystems auf deinem Computer erinnern; dies ist ein sehr treffender Vergleich! Genau wie Verzeichnisse in einem Dateisystem verwendest du Module, um deinen Code zu organisieren. Und genau wie Dateien in einem Verzeichnis brauchen wir einen Weg, unsere Module zu finden.

Mit Pfaden auf ein Element im Modulbaum verweisen

Um Rust zu zeigen, wo ein Element in einem Modulbaum zu finden ist, verwenden wir einen Pfad, auf gleiche Weise wie beim Navigieren durch ein Dateisystem. Um eine Funktion aufzurufen, müssen wir ihren Pfad kennen.

Ein Pfad kann zwei Formen annehmen:

• Ein absoluter Pfad ist der vollständige Pfad ausgehend von einer Kistenwurzel; für Code aus einer externen Kiste beginnt der absolute Pfad mit der Kistenwurzel, und für Code aus der aktuellen Kiste beginnt er mit dem Literal crate.
• Ein relativer Pfad startet beim aktuellen Modul und benutzt self, super oder einen Bezeichner im aktuellen Modul.

Sowohl absolute als auch relative Pfade bestehen aus einem oder mehreren Bezeichnern, die durch doppelte Doppelpunkte (::) getrennt sind.

Um zu Codeblock 7-1 zurückzukehren, nehmen wir an, wir wollen die Funktion add_to_waitlist aufrufen. Das ist dasselbe wie die Frage, wie der Pfad der Funktion add_to_waitlist ist. Codeblock 7-3 enthält Codeblock 7-1, wobei einige Module und Funktionen entfernt wurden.

Wir zeigen zwei Möglichkeiten, wie die Funktion add_to_waitlist von einer neuen Funktion eat_at_restaurant aus aufgerufen werden kann, die in der Kistenwurzel definiert ist. Diese Pfade sind korrekt, aber es gibt noch ein weiteres Problem, das verhindert, dass dieses Beispiel in dieser Form kompiliert. Wir werden gleich erklären, warum.

Die Funktion eat_at_restaurant ist Teil der öffentlichen Programmierschnittstelle (API) unserer Bibliothekskiste, daher markieren wir sie mit dem Schlüsselwort pub. Im Abschnitt „Pfade mit dem Schlüsselwort pub öffnen“ gehen wir näher auf pub ein.

Dateiname: src/lib.rs

#![allow(unused)]
fn main() {
mod front_of_house {
    mod hosting {
        fn add_to_waitlist() {}
    }
}

pub fn eat_at_restaurant() {
    // Absoluter Pfad
    crate::front_of_house::hosting::add_to_waitlist();

    // Relativer Pfad
    front_of_house::hosting::add_to_waitlist();
}
}

Codeblock 7-3: Aufruf der Funktion add_to_waitlist mittels absoluter und relativer Pfade

Beim ersten Aufruf der Funktion add_to_waitlist in eat_at_restaurant verwenden wir einen absoluten Pfad. Die Funktion add_to_waitlist ist in der gleichen Kiste definiert wie eat_at_restaurant, daher können wir das Schlüsselwort crate verwenden, um einen absoluten Pfad zu beginnen. Dann geben wir jedes der aufeinanderfolgenden Module an, bis wir add_to_waitlist erreichen. Du kannst dir ein Dateisystem mit der gleichen Struktur vorstellen: Wir würden den Pfad /front_of_house/hosting/add_to_waitlist angeben, um das Programm add_to_waitlist auszuführen; das Verwenden des Namens crate, um von der Kistenwurzel aus zu beginnen, ist analog zu /, um vom Dateisystem-Wurzelverzeichnis in deinem Terminal aus zu beginnen.

Beim zweiten Aufruf von add_to_waitlist in eat_at_restaurant verwenden wir einen relativen Pfad. Der Pfad beginnt mit front_of_house, dem Namen des Moduls, das auf der gleichen Ebene des Modulbaums definiert ist wie eat_at_restaurant. Hier wäre das Dateisystem-Äquivalent die Verwendung des Pfades front_of_house/hosting/add_to_waitlist. Mit einem Modulnamen zu beginnen bedeutet, dass der Pfad relativ ist.

Die Überlegung, ob ein relativer oder absoluter Pfad verwendet wird, ist eine Entscheidung, die du auf Basis deines Projekts treffen wirst, und hängt davon ab, ob du den Code für die Elementdefinition eher separat oder zusammen mit dem Code ablegen möchtest, der das Element verwendet. Wenn wir zum Beispiel das Modul front_of_house und die Funktion eat_at_restaurant in ein Modul namens customer_experience verschieben, müssten wir den absoluten Pfad in add_to_waitlist ändern, aber der relative Pfad wäre immer noch gültig. Wenn wir jedoch die Funktion eat_at_restaurant in ein separates Modul namens dining verschieben würden, würde der absolute Pfad beim Aufruf add_to_waitlist gleich bleiben, aber der relative Pfad müsste aktualisiert werden. Wir bevorzugen generell die Angabe absoluter Pfade, da es wahrscheinlicher ist, dass Codedefinitionen und Elementaufrufe unabhängig voneinander verschoben werden.

Lass uns versuchen, Codeblock 7-3 zu kompilieren, und herausfinden, warum er sich noch nicht kompilieren lässt! Der Fehler, den wir erhalten, ist in Codeblock 7-4 zu sehen.

$ cargo build
   Compiling restaurant v0.1.0 (file:///projects/restaurant)
error[E0603]: module `hosting` is private
 --> src/lib.rs:9:28
  |
9 |     crate::front_of_house::hosting::add_to_waitlist();
  |                            ^^^^^^^  --------------- function `add_to_waitlist` is not publicly re-exported
  |                            |
  |                            private module
  |
note: the module `hosting` is defined here
 --> src/lib.rs:2:5
  |
2 |     mod hosting {
  |     ^^^^^^^^^^^

error[E0603]: module `hosting` is private
  --> src/lib.rs:12:21
   |
12 |     front_of_house::hosting::add_to_waitlist();
   |                     ^^^^^^^  --------------- function `add_to_waitlist` is not publicly re-exported
   |                     |
   |                     private module
   |
note: the module `hosting` is defined here
  --> src/lib.rs:2:5
   |
2  |     mod hosting {
   |     ^^^^^^^^^^^

For more information about this error, try `rustc --explain E0603`.
error: could not compile `restaurant` (lib) due to 2 previous errors

Codeblock 7-4: Kompilierfehler im Code in Codeblock 7-3

Die Fehlermeldungen besagen, dass das Modul hosting privat ist. Mit anderen Worten, wir haben die korrekten Pfade für das Modul hosting und die Funktion add_to_waitlist angegeben, aber Rust lässt sie uns nicht nutzen, weil es keinen Zugriff auf die privaten Abschnitte hat. In Rust sind alle Elemente (Funktionen, Methoden, Strukturen, Aufzählungen, Module und Konstanten) standardmäßig privat für übergeordnete Module. Wenn du ein Element wie eine Funktion oder Struktur privat machen willst, setze es in ein Modul.

Objekte in einem übergeordneten Modul können die privaten Objekte in untergeordneten Modulen nicht verwenden, aber Objekte in untergeordneten Modulen können die Objekte in ihren übergeordneten Modulen verwenden. Der Grund dafür ist, dass untergeordnete Module ihre Implementierungsdetails ein- und ausblenden, aber die untergeordneten Module können den Gültigkeitsbereich sehen, in dem sie definiert sind. Um mit unserer Metapher fortzufahren, stelle dir die Datenschutzregeln wie das Backoffice eines Restaurants vor: Was dort drinnen passiert, ist für Restaurantkunden privat, aber Büroleiter können alles im Restaurant, in dem sie arbeiten, sehen und tun.

Rust entschied sich dafür, das Modulsystem auf diese Weise funktionieren zu lassen, sodass das Ausblenden innerer Implementierungsdetails die Vorgabe ist. Auf diese Weise weißt du, welche Teile des inneren Codes du ändern kannst, ohne den äußeren Code zu brechen. Rust gibt dir jedoch die Möglichkeit, innere Teile des Codes von Kindmodulen für äußere Vorgängermodule offenzulegen, indem du das Schlüsselwort pub verwendest, um ein Element öffentlich zu machen.

Pfade mit dem Schlüsselwort pub öffentlich machen

Kehren wir zum Fehler in Codeblock 7-4 zurück, der uns sagte, das Modul hosting sei privat. Wir wollen, dass die Funktion eat_at_restaurant im übergeordneten Modul Zugriff auf die Funktion add_to_waitlist im untergeordneten Modul hat, also markieren wir das Modul hosting mit dem Schlüsselwort pub, wie in Codeblock 7-5 gezeigt.

Dateiname: src/lib.rs

#![allow(unused)]
fn main() {
mod front_of_house {
    pub mod hosting {
        fn add_to_waitlist() {}
    }
}

pub fn eat_at_restaurant() {
    // Absoluter Pfad
    crate::front_of_house::hosting::add_to_waitlist();

    // Relativer Pfad
    front_of_house::hosting::add_to_waitlist();
}
}

Codeblock 7-5: Deklarieren des Moduls hosting als pub, um es von eat_at_restaurant aus zu benutzen

Leider führt der Code in Codeblock 7-5 immer noch zu einem Fehler, wie Codeblock 7-6 zeigt.

$ cargo build
   Compiling restaurant v0.1.0 (file:///projects/restaurant)
error[E0603]: function `add_to_waitlist` is private
 --> src/lib.rs:9:37
  |
9 |     crate::front_of_house::hosting::add_to_waitlist();
  |                                     ^^^^^^^^^^^^^^^ private function
  |
note: the function `add_to_waitlist` is defined here
 --> src/lib.rs:3:9
  |
3 |         fn add_to_waitlist() {}
  |         ^^^^^^^^^^^^^^^^^^^^

error[E0603]: function `add_to_waitlist` is private
  --> src/lib.rs:12:30
   |
12 |     front_of_house::hosting::add_to_waitlist();
   |                              ^^^^^^^^^^^^^^^ private function
   |
note: the function `add_to_waitlist` is defined here
  --> src/lib.rs:3:9
   |
3  |         fn add_to_waitlist() {}
   |         ^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0603`.
error: could not compile `restaurant` (lib) due to 2 previous errors

Codeblock 7-6: Kompilierfehler im Code in Codeblock 7-5

Was ist passiert? Das Hinzufügen des Schlüsselworts pub vor mod hosting macht das Modul öffentlich. Wenn wir auf front_of_house zugreifen können, können wir mit dieser Änderung auch auf hosting zugreifen. Aber die Inhalte von hosting sind immer noch privat; das Modul öffentlich zu machen, macht seinen Inhalt nicht öffentlich. Das Schlüsselwort pub für ein Modul erlaubt es dem Code in seinen Vorgängermodulen nur, auf das Modul zu referenzieren, nicht aber auf seinen inneren Code zuzugreifen. Da Module Container sind, können wir nicht viel tun, indem wir nur das Modul öffentlich machen; wir müssen weiter gehen und eines oder mehrere der Elemente innerhalb des Moduls ebenfalls öffentlich machen.

Die Fehler in Codeblock 7-6 besagen, dass die Funktion add_to_waitlist privat ist. Die Datenschutzregeln gelten für Strukturen, Aufzählungen, Funktionen und Methoden sowie für Module.

Lass uns auch die Funktion add_to_waitlist öffentlich machen, indem wir das Schlüsselwort pub vor ihre Definition hinzufügen, wie in Codeblock 7-7.

Dateiname: src/lib.rs

mod front_of_house {
    pub mod hosting {
        pub fn add_to_waitlist() {}
    }
}

pub fn eat_at_restaurant() {
    // Absoluter Pfad
    crate::front_of_house::hosting::add_to_waitlist();

    // Relativer Pfad
    front_of_house::hosting::add_to_waitlist();
}

Codeblock 7-7: Das Hinzufügen des Schlüsselworts pub zu mod hosting und fn add_to_waitlist lässt uns die Funktion in eat_at_restaurant aufrufen

Jetzt kompiliert der Code! Um zu sehen, warum das Hinzufügen des Schlüsselworts pub uns erlaubt, diese Pfade in add_to_waitlist im Hinblick auf die Datenschutzregeln zu verwenden, sehen wir uns die absoluten und relativen Pfade an.

Auf dem absoluten Pfad beginnen wir mit crate, der Wurzel des Modulbaums unserer Kiste. Dann wird das Modul front_of_house in der Kistenwurzel definiert. Während das Modul front_of_house nicht öffentlich ist, weil die eat_at_restaurant-Funktion im gleichen Modul wie front_of_house definiert ist (d.h. eat_at_restaurant und front_of_house sind Geschwister), können wir auf front_of_house von eat_at_restaurant aus zugreifen. Als nächstes wird das Modul hosting mit pub gekennzeichnet. Wir können auf das übergeordnete Modul von hosting zugreifen, also können wir auf hosting zugreifen. Schließlich wird die Funktion add_to_waitlist mit pub markiert und wir können auf ihr Elternmodul zugreifen, sodass dieser Funktionsaufruf klappt!

Beim relativen Pfad ist die Logik die gleiche wie beim absoluten Pfad, mit Ausnahme des ersten Schritts: Anstatt von der Kistenwurzel auszugehen, beginnt der Pfad mit front_of_house. Das Modul front_of_house wird innerhalb desselben Moduls wie eat_at_restaurant definiert, sodass der relative Pfad ausgehend vom Modul, in dem eat_at_restaurant definiert ist, funktioniert. Weil hosting und add_to_waitlist nun mit pub markiert sind, funktioniert der Rest des Pfades, und dieser Funktionsaufruf ist gültig!

Wenn du vorhast, deine Bibliothekskiste weiterzugeben, damit andere Projekte deinen Code verwenden können, ist deine öffentliche API deine Übereinkunft mit den Benutzern deiner Kiste, die festlegt, wie sie mit deinem Code interagieren können. Es gibt viele Überlegungen zum Umgang mit Änderungen an deiner öffentlichen API, um es für andere einfacher zu machen, sich auf deine Kiste zu verlassen. Diese Überlegungen liegen außerhalb des Rahmens dieses Buches; wenn du an diesem Thema interessiert bist, lies die Rust API Guidelines.

Bewährte Praktiken für Pakete mit einer Binärdatei und einer Bibliothek

Wir haben bereits erwähnt, dass ein Paket sowohl eine Binärkistenwurzel src/main.rs als auch eine Bibliothekskistenwurzel src/lib.rs enthalten kann, und beide Kisten tragen standardmäßig den Paketnamen. Normalerweise haben Pakete mit diesem Muster, die sowohl eine Bibliothek als auch eine Binärkiste enthalten, gerade genug Code in der Binärkiste, um eine ausführbare Datei zu starten, die Code aus der Bibliothekskiste aufruft. Dadurch können andere Projekte von den meisten Funktionen des Pakets profitieren, da der Code der Bibliothekskiste gemeinsam genutzt werden kann.

Der Modulbaum sollte in src/lib.rs definiert werden. Dann können alle öffentlichen Elemente in der Binärkiste verwendet werden, indem die Pfade mit dem Namen des Pakets beginnen. Die binäre Kiste wird zu einem Benutzer der Bibliothekskiste, so wie eine vollständig externe Kiste die Bibliothekskiste verwenden würde: Sie kann nur die öffentliche API verwenden. Dies hilft dir, eine gute API zu entwerfen; Du bist nicht nur der Autor, sondern auch ein Kunde!

In Kapitel 12 werden wir diese organisatorische Praxis anhand eines Befehlszeilenprogramms demonstrieren, das sowohl eine Binärkiste als auch eine Bibliothekskiste enthält.

Relative Pfade mit super beginnen

Wir können relative Pfade konstruieren, die im übergeordneten Modul beginnen und nicht im aktuellen Modul oder der Kistenwurzel, indem wir super am Anfang des Pfades verwenden. Dies ist so, als würde man einen Dateisystempfad mit der Syntax .. beginnen. Das Verwenden von super erlaubt es uns, auf ein Element zu referenzieren, von dem wir wissen, dass es sich im übergeordneten Modul befindet, was die Neuordnung des Modulbaums erleichtern kann, wenn das Modul eng mit dem übergeordneten Modul verwandt ist, aber das übergeordnete Modul eines Tages an eine andere Stelle im Modulbaum verschoben werden könnte.

Betrachte den Code in Codeblock 7-8, der die Situation nachbildet, in der ein Koch eine falsche Bestellung korrigiert und persönlich zum Kunden bringt. Die Funktion fix_incorrect_order, die im Modul back_of_house definiert ist, ruft die im übergeordneten Modul definierte Funktion deliver_order auf, indem sie den Pfad zu deliver_order angibt, der mit super beginnt:

Dateiname: src/lib.rs

#![allow(unused)]
fn main() {
fn deliver_order() {}

mod back_of_house {
    fn fix_incorrect_order() {
        cook_order();
        super::deliver_order();
    }

    fn cook_order() {}
}
}

Codeblock 7-8: Aufrufen einer Funktion unter Verwendung eines relativen Pfades, der mit super beginnt

Die Funktion fix_incorrect_order befindet sich im Modul back_of_house, sodass wir super benutzen können, um zum Elternmodul von back_of_house zu gelangen, was in diesem Fall die Wurzel crate ist. Von dort aus suchen wir nach deliver_order und finden es. Erfolg! Wir denken, dass das Modul back_of_house und die Funktion deliver_order wahrscheinlich in der gleichen Beziehung zueinander stehen und zusammen verschoben werden, sollten wir uns dazu entschließen, den Modulbaum der Kiste neu zu organisieren. Deshalb haben wir super verwendet, sodass wir in Zukunft weniger Codestellen zu aktualisieren haben, wenn dieser Code in ein anderes Modul verschoben wird.

Strukturen und Aufzählungen öffentlich machen

Wir können auch pub verwenden, um Strukturen und Aufzählungen als öffentlich zu kennzeichnen, aber es gibt ein paar zusätzliche Details zur Verwendung von pub mit Strukturen und Aufzählungen. Wenn wir pub vor einer Struktur-Definition verwenden, machen wir die Struktur öffentlich, aber die Felder der Struktur sind immer noch privat. Wir können jedes Feld von Fall zu Fall öffentlich machen oder auch nicht. In Codeblock 7-9 haben wir eine öffentliche Struktur back_of_house::Breakfast mit einem öffentlichen Feld toast, aber einem privaten Feld seasonal_fruit definiert. Dies ist der Fall in einem Restaurant, in dem der Kunde die Brotsorte auswählen kann, die zu einer Mahlzeit gehört, aber der Küchenchef entscheidet, welche Früchte die Mahlzeit begleiten, je nach Saison und Vorrat. Das verfügbare Obst ändert sich schnell, sodass die Kunden nicht wählen oder gar sehen können, welches Obst sie bekommen.

Dateiname: src/lib.rs

#![allow(unused)]
fn main() {
mod back_of_house {
    pub struct Breakfast {
        pub toast: String,
        seasonal_fruit: String,
    }

    impl Breakfast {
        pub fn summer(toast: &str) -> Breakfast {
            Breakfast {
                toast: String::from(toast),
                seasonal_fruit: String::from("Pfirsiche"),
            }
        }
    }
}

pub fn eat_at_restaurant() {
    // Bestelle im Sommer ein Frühstück mit Roggentoast
    let mut meal = back_of_house::Breakfast::summer("Roggen");
    // Ändere unsere Meinung darüber, welche Brotsorte wir gerne hätten
    meal.toast = String::from("Weizen");
    println!("Ich möchte {}-Toast", meal.toast);

    // Die nächste Zeile lässt sich nicht kompilieren, wenn wir sie nicht
    // auskommentieren; wir dürfen die Früchte der Saison, die wir mit der
    // Mahlzeit bekommen, weder sehen noch verändern.
    // meal.seasonal_fruit = String::from("Heidelbeeren");
}
}

Codeblock 7-9: Eine Struktur mit öffentlichen und privaten Feldern

Da das Feld toast in der Struktur back_of_house::Breakfast öffentlich ist, können wir in eat_at_restaurant in das Feld toast schreiben und lesen, indem wir die Punktnotation verwenden. Beachte, dass wir das Feld seasonal_fruit in eat_at_restaurant nicht verwenden können, weil seasonal_fruit privat ist. Versuche, die Kommentarzeichen in der Zeile, die den Feldwert seasonal_fruit modifiziert, zu entfernen, um zu sehen, welchen Fehler du erhältst!

Beachte auch, dass, weil back_of_house::Breakfast ein privates Feld hat, die Struktur eine öffentliche Funktion (hier haben wir sie summer genannt) zum Erzeugen einer Instanz von Breakfast bereitstellen muss. Wenn Breakfast keine solche Funktion hätte, könnten wir keine Instanz von Breakfast in eat_at_restaurant erzeugen, weil wir den Wert des privaten Feldes seasonal_fruit in eat_at_restaurant nicht setzen könnten.

Wenn wir dagegen eine Aufzählung veröffentlichen, dann sind alle ihre Varianten öffentlich. Wir brauchen nur das Schlüsselwort pub vor dem Schlüsselwort enum, wie in Codeblock 7-10 gezeigt.

Dateiname: src/lib.rs

#![allow(unused)]
fn main() {
mod back_of_house {
    pub enum Appetizer {
        Soup,
        Salad,
    }
}

pub fn eat_at_restaurant() {
    let order1 = back_of_house::Appetizer::Soup;
    let order2 = back_of_house::Appetizer::Salad;
}
}

Codeblock 7-10: Kennzeichnen einer Aufzählung als öffentlich macht alle ihre Varianten öffentlich

Da wir die Aufzählung Appetizer öffentlich gemacht haben, können wir die Varianten Soup und Salad in eat_at_restaurant verwenden.

Aufzählungen wären ohne öffentliche Varianten nicht sehr nützlich; es wäre ärgerlich, alle Aufzählungs-Varianten stets mit pub annotieren zu müssen, daher sind die Aufzählungs-Varianten standardmäßig öffentlich. Strukturen sind auch ohne öffentliche Felder nützlich, daher folgen Strukturfelder standardmäßig der allgemeinen Regel, dass alles privat ist, es sei denn, es wird mit pub annotiert.

Es gibt noch eine weitere Situation mit pub, die wir noch nicht behandelt haben, und das ist unser letztes Modulsystem-Feature: Das Schlüsselwort use. Zuerst werden wir use an sich behandeln, und dann zeigen wir, wie man pub und use kombiniert.

Pfade in den Gültigkeitsbereich bringen mit dem Schlüsselwort use

Die Pfade für den Aufruf von Funktionen auszuschreiben, kann lästig sein und sich wiederholen. In Codeblock 7-7 mussten wir, unabhängig davon, ob wir den absoluten oder relativen Pfad zur Funktion add_to_waitlist wählten, jedes Mal, wenn wir add_to_waitlist aufrufen wollten, auch front_of_house und hosting angeben. Glücklicherweise gibt es eine Möglichkeit, diesen Vorgang zu vereinfachen: Wir können eine Verknüpfung zu einem Pfad mit dem Schlüsselwort use einmal erstellen und dann den kürzeren Namen überall sonst im Gültigkeitsbereich verwenden.

In Codeblock 7-11 bringen wir das Modul crate::front_of_house::hosting in den Gültigkeitsbereich der Funktion eat_at_restaurant, sodass wir nur noch hosting::add_to_waitlist angeben müssen, um die Funktion add_to_waitlist in eat_at_restaurant aufzurufen.

Dateiname: src/lib.rs

mod front_of_house {
    pub mod hosting {
        pub fn add_to_waitlist() {}
    }
}

use crate::front_of_house::hosting;

pub fn eat_at_restaurant() {
    hosting::add_to_waitlist();
}

Codeblock 7-11: Ein Modul mit use in den Gültigkeitsbereich bringen

Das Angeben von use und einem Pfad in einem Gültigkeitsbereich ist ähnlich dem Erstellen eines symbolischen Links im Dateisystem. Durch Hinzufügen von use crate::front_of_house::hosting in der Kistenwurzel ist hosting nun ein gültiger Name in diesem Gültigkeitsbereich, so als wäre das Modul hosting in der Kistenwurzel definiert worden. Pfade, die mit use in den Gültigkeitsbereich gebracht werden, überprüfen wie alle anderen Pfade auch die Privatsphäre.

Beachte, dass use nur die Verknüpfung für den jeweiligen Gültigkeitsbereich erstellt, in dem use vorkommt. Codeblock 7-12 verschiebt die Funktion eat_at_restaurant in ein neues untergeordnetes Modul namens customer, das dann einen anderen Gültigkeitsbereich als die use-Anweisung hat, sodass der Funktionsrumpf nicht kompiliert werden kann:

Dateiname: src/lib.rs

mod front_of_house {
    pub mod hosting {
        pub fn add_to_waitlist() {}
    }
}

use crate::front_of_house::hosting;

mod customer {
    pub fn eat_at_restaurant() {
        hosting::add_to_waitlist();
    }
}

Codeblock 7-12: Eine use-Anweisung gilt nur in dem Gültigkeitsbereich, in dem sie steht

Der Compilerfehler zeigt, dass die Verknüpfung innerhalb des Moduls customer nicht mehr gilt:

$ cargo build
   Compiling restaurant v0.1.0 (file:///projects/restaurant)
error[E0433]: failed to resolve: use of undeclared crate or module `hosting`
  --> src/lib.rs:11:9
   |
11 |         hosting::add_to_waitlist();
   |         ^^^^^^^ use of undeclared crate or module `hosting`
   |
help: consider importing this module through its public re-export
   |
10 +     use crate::hosting;
   |

warning: unused import: `crate::front_of_house::hosting`
 --> src/lib.rs:7:5
  |
7 | use crate::front_of_house::hosting;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

For more information about this error, try `rustc --explain E0433`.
warning: `restaurant` (lib) generated 1 warning
error: could not compile `restaurant` (lib) due to 1 previous error; 1 warning emitted

Beachte, dass es auch eine Warnung gibt, dass use nicht mehr in seinem Gültigkeitsbereich verwendet wird! Um dieses Problem zu beheben, verschiebe use auch innerhalb des Moduls customer, oder referenziere die Verknüpfung im übergeordneten Modul mit super::hosting innerhalb des untergeordneten Moduls customer.

Idiomatische use-Pfade erstellen

In Codeblock 7-11 hast du dich vielleicht gefragt, warum wir use crate::front_of_house::hosting angegeben und dann hosting::add_to_waitlist in eat_at_restaurant aufgerufen haben, anstatt den use-Pfad bis hin zur Funktion add_to_waitlist anzugeben, um dasselbe Ergebnis zu erzielen wie in Codeblock 7-13.

Dateiname: src/lib.rs

mod front_of_house {
    pub mod hosting {
        pub fn add_to_waitlist() {}
    }
}

use crate::front_of_house::hosting::add_to_waitlist;

pub fn eat_at_restaurant() {
    add_to_waitlist();
}

Codeblock 7-13: Die Funktion add_to_waitlist mit use in den Gültigkeitsbereich bringen ist nicht idiomatisch.

Obwohl sowohl Codeblock 7-11 als auch Codeblock 7-13 die gleiche Aufgabe erfüllen, ist Codeblock 7-11 der idiomatische Weg, eine Funktion mit use in den Gültigkeitsbereich zu bringen. Wenn wir das Elternmodul der Funktion mit use in den Gültigkeitsbereich bringen, sodass wir das Elternmodul beim Aufruf der Funktion angeben müssen, wird klar, dass die Funktion nicht lokal definiert ist, während gleichzeitig die Wiederholung des vollständigen Pfades minimiert wird. Im Code in Codeblock 7-13 ist unklar, wo add_to_waitlist definiert ist.

Wenn andererseits Strukturen, Aufzählungen und andere Elemente mit use eingebracht werden, ist es idiomatisch, den vollständigen Pfad anzugeben. Codeblock 7-14 zeigt den idiomatischen Weg, die Struktur HashMap der Standardbibliothek in den Gültigkeitsbereich einer binären Kiste zu bringen.

Dateiname: src/main.rs

use std::collections::HashMap;

fn main() {
    let mut map = HashMap::new();
    map.insert(1, 2);
}

Codeblock 7-14: HashMap auf idiomatische Weise in den Gültigkeitsbereich bringen

Es gibt keinen triftigen Grund für dieses Idiom: Es ist einfach eine Konvention, die entstanden ist, und die Leute haben sich daran gewöhnt, Rust-Code auf diese Weise zu lesen und zu schreiben.

Die Ausnahme von diesem Idiom ist, wenn wir zwei gleichnamige Elemente mit use in den Gültigkeitsbereich bringen, denn das lässt Rust nicht zu. In Codeblock 7-15 wird gezeigt, wie zwei Result-Typen mit gleichem Namen, aber unterschiedlichen Elternmodulen in den Gültigkeitsbereich gebracht werden und wie auf sie verwiesen werden kann.

Dateiname: src/lib.rs

#![allow(unused)]
fn main() {
use std::fmt;
use std::io;

fn function1() -> fmt::Result {
    // --abschneiden--
    Ok(())
}

fn function2() -> io::Result<()> {
    // --abschneiden--
    Ok(())
}
}

Codeblock 7-15: Um zwei Typen mit dem gleichen Namen in denselben Gültigkeitsbereich zu bringen, müssen ihre übergeordneten Module angegeben werden.

Wie du sehen kannst, unterscheidet die Verwendung der übergeordneten Module die beiden Result-Typen. Wenn wir stattdessen use std::fmt::Result und use std::io::Result angeben würden, hätten wir zwei Result-Typen im selben Gültigkeitsbereich und Rust wüsste nicht, welchen wir beim Verwenden von Result meinten.

Mit dem Schlüsselwort as neue Namen vergeben

Es gibt eine andere Lösung für das Problem, zwei Typen desselben Namens mit use in den gleichen Gültigkeitsbereich zu bringen: Hinter dem Pfad können wir as und einen neuen lokalen Namen oder Alias für den Typ angeben. Codeblock 7-16 zeigt eine weitere Möglichkeit, den Code in Codeblock 7-15 zu schreiben, indem einer der beiden Result-Typen mittels as umbenannt wird.

Dateiname: src/lib.rs

#![allow(unused)]
fn main() {
use std::fmt::Result;
use std::io::Result as IoResult;

fn function1() -> Result {
    // --abschneiden--
    Ok(())
}

fn function2() -> IoResult<()> {
    // --abschneiden--
    Ok(())
}
}

Codeblock 7-16: Umbenennen eines Typs, wenn er mit dem Schlüsselwort as in den Gültigkeitsbereich gebracht wird

In der zweiten use-Anweisung wählten wir den neuen Namen IoResult für den Typ std::io::Result, der nicht im Konflikt zum ebenfalls von uns in den Gültigkeitsbereich gebrachten Result aus std::fmt steht. Codeblock 7-15 und Codeblock 7-16 gelten als idiomatisch, die Wahl liegt also bei dir!

Rück-Exportieren von Namen mit pub use

Wenn wir einen Namen mit dem Schlüsselwort use in den Gültigkeitsbereich bringen, ist der im neuen Gültigkeitsbereich verfügbare Name privat. Damit der Code, der unseren Code aufruft, auf diesen Namen verweisen kann, als wäre er im Gültigkeitsbereich dieses Codes definiert worden, können wir pub und use kombinieren. Diese Technik wird Rück-Exportieren (re-exporting) genannt, weil wir ein Element in den Gültigkeitsbereich bringen, dieses Element aber auch anderen zur Verfügung stellen, um es in ihren Gültigkeitsbereich zu bringen.

Codeblock 7-17 zeigt den Code in Codeblock 7-11, wobei use im Wurzelmodul in pub use geändert wurde.

Dateiname: src/lib.rs

mod front_of_house {
    pub mod hosting {
        pub fn add_to_waitlist() {}
    }
}

pub use crate::front_of_house::hosting;

pub fn eat_at_restaurant() {
    hosting::add_to_waitlist();
}

Codeblock 7-17: Bereitstellen eines Namens für externen Code zum Verwenden in einem neuen Gültigkeitsbereich mit pub use

Vor dieser Änderung musste externer Code die Funktion add_to_waitlist mit dem Pfad restaurant::front_of_house::hosting::add_to_waitlist() aufrufen. Nun, da pub use das Modul hosting aus dem Wurzel-Modul re-exportiert hat, kann externer Code nun stattdessen den Pfad restaurant::hosting::add_to_waitlist() verwenden.

Der Rück-Export ist nützlich, wenn sich die interne Struktur deines Codes von dem unterscheidet, wie Programmierer, die deinen Code aufrufen, über die Domäne denken würden. In der Restaurantmetapher denken die Betreiber des Restaurants zum Beispiel an die „Vorderseite des Hauses“ und die „Rückseite des Hauses“. Mit pub use können wir unseren Code mit einer Struktur schreiben, aber eine andere Struktur veröffentlichen. Auf diese Weise ist unsere Bibliothek für Programmierer, die an der Bibliothek arbeiten, und Programmierer, die die Bibliothek aufrufen, gut organisiert. Ein weiteres Beispiel für pub use und wie es sich auf die Dokumentation deiner Kiste auswirkt, werden wir im Abschnitt „Mit pub use eine benutzerfreundliche öffentliche API exportieren“ in Kapitel 14 betrachten.

Verwenden externer Pakete

In Kapitel 2 programmierten wir ein Ratespielprojekt, das ein externes Paket namens rand benutzte, um Zufallszahlen zu generieren. Um rand in unserem Projekt zu verwenden, fügten wir diese Zeile zu Cargo.toml hinzu:

Dateiname: Cargo.toml

rand = "0.8.5"

Das Hinzufügen von rand als Abhängigkeit in Cargo.toml weist Cargo an, das Paket rand und alle Abhängigkeiten von crates.io herunterzuladen und rand für unser Projekt verfügbar zu machen.

Um dann Definitionen von rand in den Gültigkeitsbereich unseres Pakets aufzunehmen, haben wir eine Zeile mit use hinzugefügt, die mit dem Kistennamen rand beginnt und die Elemente auflistet, die wir in den Gültigkeitsbereich bringen wollten. Erinnere dich, dass wir im Abschnitt „Generieren einer Geheimzahl“ in Kapitel 2 das Merkmal Rng in den Gültigkeitsbereich gebracht und die Funktion rand::thread_rng aufgerufen haben:

use std::io;
use rand::Rng;

fn main() {
    println!("Rate die Zahl!");

    let secret_number = rand::thread_rng().gen_range(1..=100);

    println!("Die geheime Zahl ist: {}", secret_number);

    println!("Bitte gib deine Vermutung ein.");

    let mut guess = String::new();

    io::stdin()
        .read_line(&mut guess)
        .expect("Fehler beim Lesen einer Zeile");

    println!("Du hast geraten: {}", guess);
}

Mitglieder der Rust-Gemeinschaft haben viele Pakete unter crates.io zur Verfügung gestellt und wenn du eines davon in dein Paket aufnimmst, sind die gleichen Schritte erforderlich: Liste sie in der Datei Cargo.toml deines Pakets auf und verwende use, um Elemente aus ihren Kisten in den Gültigkeitsbereich zu bringen.

Beachte, dass die Standardbibliothek std ebenfalls eine Kiste ist, die nicht zu unserem Paket gehört. Da die Standardbibliothek mit der Sprache Rust ausgeliefert wird, brauchen wir Cargo.toml nicht zu ändern, um std einzubinden. Aber wir müssen use verwenden, um Elemente von dort in den Gültigkeitsbereich unseres Pakets zu bringen. Zum Beispiel würden wir für HashMap diese Zeile verwenden:

#![allow(unused)]
fn main() {
use std::collections::HashMap;
}

Dies ist ein absoluter Pfad, der mit std, dem Namen der Standard-Bibliothekskiste, beginnt.

Verschachtelte Pfade verwenden, um lange use-Listen zu vereinfachen

Wenn wir mehrere in der gleichen Kiste oder im gleichen Modul definierte Elemente verwenden, kann das Auflisten jedes Elements in einer eigenen Zeile viel vertikalen Platz in unseren Dateien einnehmen. Zum Beispiel bringen diese beiden use-Anweisungen, die wir im Ratespiel in Codeblock 2-4 hatten, Elemente aus std in den Gültigkeitsbereich:

Dateiname: src/main.rs

#![allow(unused)]
fn main() {
// --abschneiden--
use std::cmp::Ordering;
use std::io;
// --abschneiden--
}

Stattdessen können wir verschachtelte Pfade verwenden, um die gleichen Elemente in einer Zeile in den Gültigkeitsbereich zu bringen. Wir tun dies, indem wir den gemeinsamen Teil des Pfades angeben, gefolgt von zwei Doppelpunkten und dann geschweiften Klammern um Liste der Pfadteile, die sich unterscheiden, wie in Codeblock 7-18 gezeigt.

Dateiname: src/main.rs

#![allow(unused)]
fn main() {
// --abschneiden--
use std::{cmp::Ordering, io};
// --abschneiden--
}

Codeblock 7-18: Angeben eines verschachtelten Pfades, um mehrere Elemente mit demselben Präfix in den Gültigkeitsbereich zu bringen

In größeren Programmen kann das Einbeziehen vieler Elemente aus derselben Kiste oder demselben Modul in den Gültigkeitsbereich durch verschachtelte Pfade die Anzahl der separaten use-Anweisungen um ein Vielfaches reduzieren!

Wir können einen verschachtelten Pfad auf jeder Ebene in einem Pfad verwenden, was nützlich ist, wenn zwei use-Anweisungen kombiniert werden, die sich einen Teilpfad teilen. Beispielsweise zeigt Codeblock 7-19 zwei use-Anweisungen: Eine, die std::io in den Gültigkeitsbereich bringt, und eine, die std::io::Write in den Gültigkeitsbereich bringt.

Dateiname: src/lib.rs

#![allow(unused)]
fn main() {
use std::io;
use std::io::Write;
}

Codeblock 7-19: Zwei use-Anweisungen, bei denen eine ein Teilpfad der anderen ist

Der gemeinsame Teil dieser beiden Pfade ist std::io und das ist der vollständige erste Pfad. Um diese beiden Pfade zu einer einzigen use-Anweisung zu verschmelzen, können wir self im verschachtelten Pfad verwenden, wie in Codeblock 7-20 gezeigt wird.

Dateiname: src/lib.rs

#![allow(unused)]
fn main() {
use std::io::{self, Write};
}

Codeblock 7-20: Zusammenfassen der Pfade aus Codeblock 7-19 zu einer use-Anweisung

Diese Zeile bringt std::io und std::io::Write in den Gültigkeitsbereich.

Der Stern-Operator (glob)

Wenn wir alle öffentlichen Elemente, die in einem Pfad definiert sind, in den Gültigkeitsbereich bringen wollen, können wir diesen Pfad gefolgt vom Stern-Operator * angeben:

#![allow(unused)]
fn main() {
use std::collections::*;
}

Diese use-Anweisung bringt alle öffentlichen Elemente, die in std::collections definiert sind, in den aktuellen Gültigkeitsbereich. Sei vorsichtig beim Verwenden des Stern-Operators! Er kann es schwieriger machen, zu erkennen, welche Namen in den Gültigkeitsbereich fallen und wo ein in deinem Programm verwendeter Name definiert wurde.

Der Stern-Operator wird oft beim Testen verwendet, um alles, was getestet wird, in das Modul tests zu bringen. Wir werden darüber im Abschnitt „Tests schreiben“ in Kapitel 11 sprechen. Der Stern-Operator wird manchmal auch als Teil des Präludiumsmusters (prelude pattern) verwendet: Siehe Standardbibliotheksdokumentation für weitere Informationen zu diesem Muster.

Module in verschiedene Dateien aufteilen

Bisher haben alle Beispiele in diesem Kapitel mehrere Module in einer Datei definiert. Wenn Module groß werden, solltest du ihre Definitionen in eine separate Datei verschieben, um die Navigation im Code zu erleichtern.

Gehen wir zum Beispiel von dem Code in Codeblock 7-17 aus, der mehrere Restaurantmodule enthält. Wir verschieben das Modul front_of_house in seine eigene Datei src/front_of_house.rs, indem wir die Kistenwurzeldatei so ändern, dass sie den in Codeblock 7-21 gezeigten Code enthält. In diesem Fall ist die Kistenwurzeldatei src/lib.rs, aber diese Vorgehensweise funktioniert auch mit binären Kisten, deren Kistenwurzeldatei src/main.rs ist.

Zuerst extrahieren wir das Modul front_of_house in eine eigene Datei. Entferne den Code innerhalb der geschweiften Klammern des Moduls front_of_house und lasse nur die Deklaration mod front_of_house; übrig, sodass src/lib.rs den in Codeblock 7-21 gezeigten Code enthält. Beachte, dass dies nicht kompiliert und wir noch die Datei src/front_of_house.rs in Codeblock 7-22 erstellen müssen.

Dateiname: src/lib.rs

mod front_of_house;

pub use crate::front_of_house::hosting;

pub fn eat_at_restaurant() {
    hosting::add_to_waitlist();
}

Codeblock 7-21: Deklarieren des Moduls front_of_house, dessen Rumpf sich in src/front_of_house.rs befinden wird

Als nächstes fügst du den Code in den geschweiften Klammern in eine neue Datei namens src/front_of_house.rs ein, wie in Codeblock 7-22 zu sehen ist. Der Compiler weiß, dass er in dieser Datei suchen muss, weil er auf die Moduldeklaration in der Kistenwurzel mit dem Namen front_of_house gestoßen ist.

Dateiname: src/front_of_house.rs

pub mod hosting {
    pub fn add_to_waitlist() {}
}

Codeblock 7-22: Definitionen innerhalb des Moduls front_of_house in src/front_of_house.rs

Beachte, dass du den Inhalt einer Datei mit einer mod-Deklaration nur einmal in deinem Modulbaum laden musst. Sobald der Compiler weiß, dass die Datei Teil des Projekts ist (und weiß, wo im Modulbaum sich der Code befindet, weil du die mod-Anweisung eingefügt hast), sollten andere Dateien in deinem Projekt auf den Code der geladenen Datei referenzieren, indem sie einen Pfad zu der Stelle verwenden, an der er deklariert wurde, wie im Abschnitt „Mit Pfaden auf ein Element im Modulbaum verweisen“ beschrieben. Mit anderen Worten: mod ist keine „include“-Operation, wie du sie vielleicht aus anderen Programmiersprachen kennst.

Als Nächstes extrahieren wir das Modul hosting in seine eigene Datei. Der Prozess ist ein bisschen anders, weil hosting ein untergeordnetes Modul von front_of_house ist, nicht vom Stammmodul. Wir legen die Datei für hosting in einem neuen Verzeichnis ab, das nach seinen Vorgängern im Modulbaum benannt wird, in diesem Fall src/front_of_house/.

Um mit dem Verschieben von hosting zu beginnen, ändern wir src/front_of_house.rs so, dass es nur die Deklaration des hosting-Moduls enthält:

Dateiname: src/front_of_house.rs

pub mod hosting;

Dann erstellen wir ein Verzeichnis src/front_of_house und eine Datei hosting.rs, die die Definitionen des Moduls hosting enthält:

Dateiname: src/front_of_house/hosting.rs

#![allow(unused)]
fn main() {
pub fn add_to_waitlist() {}
}

Wenn wir stattdessen hosting.rs in das src-Verzeichnis legen, würde der Compiler erwarten, dass der hosting.rs-Code in einem hosting-Modul enthalten ist, das im Stammverzeichnis der Kiste deklariert ist, und nicht als Kind des front_of_house-Moduls. Die Regeln des Compilers dafür, welche Dateien auf den Code welcher Module zu prüfen sind, bedeuten, dass die Verzeichnisse und Dateien dem Modulbaum besser entsprechen.

Alternative Dateipfade

Bis jetzt haben wir die idiomatischsten Dateipfade behandelt, die der Rust-Compiler verwendet, aber Rust unterstützt auch eine ältere Art von Dateipfaden. Für ein Modul mit dem Namen front_of_house, das in der Kistenwurzel deklariert ist, sucht der Compiler den Code des Moduls in:

• src/front_of_house.rs (was wir behandelt haben)
• src/front_of_house/mod.rs (älterer Stil, noch unterstützter Pfad)

Bei einem Modul mit dem Namen hosting, das ein Untermodul von front_of_house ist, sucht der Compiler den Code des Moduls in:

• src/front_of_house/hosting.rs (was wir behandelt haben)
• src/front_of_house/hosting/mod.rs (älterer Stil, noch unterstützter Pfad)

Wenn du beide Stile für dasselbe Modul verwendest, erhältst einen Compilerfehler. Die Verwendung einer Mischung beider Stile für verschiedene Module im selben Projekt ist zulässig, kann aber für die Benutzer verwirrend sein, die durch dein Projekt navigieren.

Der größte Nachteil des Stils, der Dateien mit dem Namen mod.rs verwendet, ist, dass dein Projekt am Ende viele Dateien mit dem Namen mod.rs haben kann, was verwirrend sein kann, wenn du sie gleichzeitig in deinem Editor geöffnet hast.

Wir haben den Code jedes Moduls in eine separate Datei verschoben, und der Modulbaum bleibt derselbe. Die Funktionsaufrufe in eat_at_restaurant funktionieren ohne jede Änderung, auch wenn die Definitionen in verschiedenen Dateien stehen. Mit dieser Technik kannst du Module in neue Dateien verschieben, wenn diese größer werden.

Beachte, dass sich die Anweisung pub use crate::front_of_house::hosting in src/lib.rs ebenfalls nicht geändert hat und dass use keinen Einfluss darauf hat, welche Dateien als Teil der Kiste kompiliert werden. Das Schlüsselwort mod deklariert Module und Rust sucht in einer Datei mit dem Modulnamen nach dem Code, der zu diesem Modul gehört.

Zusammenfassung

Mit Rust kannst du ein Paket in mehrere Kisten und eine Kiste in Module aufteilen, sodass du auf in einem Modul definierte Elemente aus einem anderen Modul verweisen kannst. Du kannst dies tun, indem du absolute oder relative Pfade angibst. Diese Pfade können mit einer use-Anweisung in den Gültigkeitsbereich gebracht werden, sodass du einen kürzeren Pfad für mehrere Verwendungen des Elements in diesem Gültigkeitsbereich angeben kannst. Der Modulcode ist standardmäßig privat, aber du kannst Definitionen öffentlich machen, indem du das Schlüsselwort pub angibst.

Im nächsten Kapitel werden wir uns einige Kollektionsdatenstrukturen in der Standardbibliothek ansehen, die du in deinem ordentlich organisierten Code verwenden kannst.

Allgemeine Kollektionen

Die Standardbibliothek von Rust enthält eine Reihe sehr nützlicher Datenstrukturen, die Kollektionen (collections) genannt werden. Die meisten anderen Datentypen repräsentieren einen bestimmten Wert, aber Kollektionen können mehrere Werte enthalten. Im Gegensatz zu den eingebauten Array- und Tupel-Typen werden die Daten, auf die diese Kollektionen zeigen, im dynamischen Speicher abgelegt. Somit muss die Datenmenge zum Kompilierzeitpunkt nicht bekannt sein und kann während der Programmausführung wachsen oder schrumpfen. Jede Kollektionsart hat unterschiedliche Fähigkeiten und Kosten, und die Auswahl einer für deine aktuelle Situation geeigneten Kollektion ist eine Fähigkeit, die du im Laufe der Zeit entwickeln wirst. In diesem Kapitel besprechen wir drei Kollektionen, die sehr häufig in Rust-Programmen verwendet werden:

• Ein Vektor erlaubt es dir, eine variable Anzahl von Werten nebeneinander zu speichern.
• Eine Zeichenkette ist eine Kollektion von Zeichen. Wir haben den Typ String bereits kennengelernt, aber in diesem Kapitel werden wir ausführlich darauf eingehen.
• Eine Hashtabelle (hash map) erlaubt es dir, einen Wert mit einem bestimmten Schlüssel zu assoziieren. Es ist eine spezielle Implementierung der allgemeineren Datenstruktur, die assoziatives Datenfeld (map) genannt wird.

Informationen über weitere Kollektionsarten, die von der Standardbibliothek bereitgestellt werden, findest du in der Dokumentation.

Wir werden erörtern, wie Vektoren, Zeichenketten und Hashtabellen erstellt und aktualisiert werden und was jede einzelne besonders macht.

Wertlisten in Vektoren ablegen

Der erste Kollektionstyp, den wir betrachten werden, ist Vec<T>, auch bekannt als Vektor. Vektoren ermöglichen es dir, mehr als einen Wert in einer einzigen Datenstruktur zu speichern und alle Werte nebeneinander im Speicher abzulegen. Vektoren können nur Werte desselben Typs speichern. Sie sind nützlich, wenn du eine Liste von Einträgen hast, z.B. die Textzeilen einer Datei oder die Preise der Artikel in einem Einkaufswagen.

Erstellen eines neuen Vektors

Um einen neuen, leeren Vektor zu erstellen, rufen wir die Funktion Vec::new auf, wie in Codeblock 8-1 gezeigt.

#![allow(unused)]
fn main() {
let v: Vec<i32> = Vec::new();
}

Codeblock 8-1: Erstellen eines neuen, leeren Vektors zur Aufnahme von Werten des Typs i32

Beachte, dass wir hier eine Typ-Annotation hinzugefügt haben. Da wir keine Werte in diesen Vektor einfügen, weiß Rust nicht, welche Art von Elementen wir zu speichern beabsichtigen. Dies ist ein wichtiger Punkt. Vektoren werden mit Hilfe generischer Typen implementiert; wie du eigene generische Typen verwenden kannst, wird in Kapitel 10 behandelt. Für den Moment sollst du wissen, dass der von der Standardbibliothek bereitgestellte Typ Vec<T> jeden Typ enthalten kann. Wenn wir einen Vektor zu einem bestimmten Typ erstellen, wird der Typ in spitzen Klammern angegeben. In Codeblock 8-1 haben wir Rust gesagt, dass der Vektor Vec<T> in v Elemente des Typs i32 enthalten wird.

Meistens wird man ein Vec<T> mit Anfangswerten erstellen und Rust wird den Typ des Wertes, den man speichern will, ableiten, sodass man diese Typ-Annotation nur selten benötigt. Rust bietet praktischerweise das Makro vec!, das einen neuen Vektor erzeugt, der die von dir angegebenen Werte enthält. Codeblock 8-2 erzeugt einen neuen Vec<i32>, der die Werte 1, 2 und 3 enthält. Als Integer-Typ wird i32 verwendet, weil das der Standard-Integer-Typ ist, wie wir im Abschnitt „Datentypen“ in Kapitel 3 besprochen haben.

#![allow(unused)]
fn main() {
let v = vec![1, 2, 3];
}

Codeblock 8-2: Erstellen eines neuen Vektors mit Werten

Da wir initiale i32-Werte angegeben haben, kann Rust daraus schließen, dass v den Typ Vec<i32> hat, und die Typ-Annotation ist nicht notwendig. Als Nächstes werden wir uns ansehen, wie man einen Vektor modifiziert.

Aktualisieren eines Vektors

Um einen Vektor zu erstellen und ihm dann Elemente hinzuzufügen, können wir die Methode push verwenden, wie in Codeblock 8-3 zu sehen ist.

#![allow(unused)]
fn main() {
let mut v = Vec::new();

v.push(5);
v.push(6);
v.push(7);
v.push(8);
}

Codeblock 8-3: Verwenden der Methode push zum Hinzufügen von Werten zu einem Vektor

Wie bei jeder Variablen müssen wir, wenn wir ihren Wert ändern wollen, sie mit dem Schlüsselwort mut als veränderbar markieren, wie in Kapitel 3 besprochen. Die Zahlen, die wir darin platzieren, sind alle vom Typ i32, und Rust leitet dies aus den Daten ab, sodass wir die Annotation Vec<i32> nicht benötigen.

Elemente aus Vektoren lesen

Es gibt zwei Möglichkeiten, einen in einem Vektor gespeicherten Wert zu referenzieren. In den Beispielen haben wir zur besseren Lesbarkeit die Werttypen, die von den Funktionen zurückgegeben werden, mit angegeben.

Codeblock 8-4 zeigt beide Zugriffsmethoden auf einen Wert in einem Vektor, mittels Indexierungssyntax und der Methode get.

#![allow(unused)]
fn main() {
let v = vec![1, 2, 3, 4, 5];

let third: &i32 = &v[2];
println!("Das dritte Element ist {third}");

let third: Option<&i32> = v.get(2);
match third {
    Some(third) => println!("Das dritte Element ist {third}"),
    None => println!("Es gibt kein drittes Element."),
}
}

Codeblock 8-4: Verwenden der Indexierungssyntax und der Methode get für den Zugriff auf ein Element in einem Vektor

Beachte hier einige Details. Wir verwenden den Indexwert 2, um das dritte Element zu erhalten, da Vektoren mit Zahlen beginnend bei null indiziert werden. Mit & und [] erhalten wir eine Referenz auf das Element mit dem Indexwert. Wenn wir die Methode get mit dem Index als Argument verwenden, erhalten wir eine Option<&T>, die wir mit match verwenden können.

Der Grund, warum Rust diese beiden Möglichkeiten, auf ein Element zu referenzieren, bietet ist, dass du wählen kannst, wie sich das Programm verhält, wenn du versuchst, einen Indexwert außerhalb des Bereichs der vorhandenen Elemente zu verwenden. Als Beispiel wollen wir sehen, was ein Programm tut, wenn wir bei einem Vektor mit fünf Elementen versuchen, auf ein Element mit Index 100 zuzugreifen, wie in Codeblock 8-5 zu sehen ist.

#![allow(unused)]
fn main() {
let v = vec![1, 2, 3, 4, 5];

let does_not_exist = &v[100];
let does_not_exist = v.get(100);
}

Codeblock 8-5: Versuch, auf das Element mit Index 100 in einem Vektor zuzugreifen, der fünf Elemente enthält

Wenn wir diesen Code ausführen, wird die erste [] Variante das Programm abbrechen lassen, weil es auf ein nicht existierendes Element verweist. Diese Methode wird vorzugsweise verwendet, wenn du dein Programm abstürzen lassen möchtest, wenn versucht wird, auf ein Element hinter dem Ende des Vektors zuzugreifen.

Wenn der Methode get ein Index außerhalb des Vektors übergeben wird, gibt sie None zurück, ohne abzubrechen. Du würdest diese Methode verwenden, wenn der Zugriff auf ein Element außerhalb des Bereichs des Vektors unter normalen Umständen gelegentlich vorkommt. Dein Code wird dann eine Logik haben, die mit Some(&element) und None umgehen kann, wie in Kapitel 6 besprochen. Der Index könnte zum Beispiel von einer Person stammen, die eine Zahl eingibt. Wenn sie versehentlich eine zu große Zahl eingibt und das Programm einen None-Wert erhält, kannst du dem Benutzer mitteilen, wie viele Elemente sich aktuell im Vektor befinden und ihm eine weitere Chance geben, einen gültigen Wert einzugeben. Das wäre benutzerfreundlicher, als das Programm wegen eines Tippfehlers abstürzen zu lassen!

Wenn das Programm über eine gültige Referenz verfügt, stellt der Ausleihenprüfer mittels Eigentümerschafts- und Ausleihregeln (siehe Kapitel 4) sicher, dass diese Referenz und alle anderen Referenzen auf den Inhalt des Vektors gültig bleiben. Erinnere dich an die Regel, die besagt, dass du keine veränderbaren und unveränderbaren Referenzen im gleichen Gültigkeitsbereich haben kannst. Diese Regel trifft in Codeblock 8-6 zu, wo wir eine unveränderbare Referenz auf das erste Element in einem Vektor halten und versuchen, am Ende ein Element hinzuzufügen. Das wird nicht funktionieren, wenn wir später in der Funktion versuchen auch auf dieses Element zuzugreifen:

#![allow(unused)]
fn main() {
let mut v = vec![1, 2, 3, 4, 5];

let first = &v[0];

v.push(6);

println!("Das erste Element ist: {first}");
}

Codeblock 8-6: Versuch, ein Element zu einem Vektor hinzuzufügen, während eine Referenz auf ein Element gehalten wird

Das Kompilieren dieses Codes führt zu folgendem Fehler:

$ cargo run
   Compiling collections v0.1.0 (file:///projects/collections)
error[E0502]: cannot borrow `v` as mutable because it is also borrowed as immutable
 --> src/main.rs:6:5
  |
4 |     let first = &v[0];
  |                  - immutable borrow occurs here
5 | 
6 |     v.push(6);
  |     ^^^^^^^^^ mutable borrow occurs here
7 | 
8 |     println!("Das erste Element ist: {first}");
  |                                      ------- immutable borrow later used here

For more information about this error, try `rustc --explain E0502`.
error: could not compile `collections` (bin "collections") due to 1 previous error

Der Code in Codeblock 8-6 sieht so aus, als könnte er funktionieren: Warum sollte sich eine Referenz auf das erste Element darum kümmern, was sich am Ende des Vektors ändert? Dieser Fehler ist in der Funktionsweise von Vektoren begründet: Weil Vektoren die Werte nebeneinander im Speicher ablegen, könnte das Hinzufügen eines neuen Elements am Ende des Vektors die Allokation neuen Speichers und das Kopieren der alten Elemente an die neue Stelle erfordern, wenn nicht genügend Platz vorhanden ist, um alle Elemente nebeneinander an der aktuellen Stelle des Vektors zu platzieren. In diesem Fall würde die Referenz auf das erste Element auf einen freigegebenen Speicherplatz verweisen. Die Ausleihregeln verhindern, dass Programme in diese Situation geraten.

Anmerkung: Weitere Einzelheiten zu den Implementierungsdetails des Typs Vec<T> findest du in „Das Rustonomicon“.

Iterieren über die Werte in einem Vektor

Um auf die Elemente eines Vektors der Reihe nach zuzugreifen, können wir über alle Elemente iterieren, anstatt Indizes zu verwenden, um auf jeweils ein Element zur gleichen Zeit zuzugreifen. Codeblock 8-7 zeigt, wie man eine for-Schleife verwendet, um unveränderbare Referenzen auf die Elemente eines Vektors von i32-Werten zu erhalten und diese auszugeben.

#![allow(unused)]
fn main() {
let v = vec![100, 32, 57];
for i in &v {
    println!("{i}");
}
}

Codeblock 8-7: Ausgeben aller Elemente eines Vektors durch Iterieren über die Elemente mittels for-Schleife

Wir können auch über veränderbare Referenzen der Elemente eines veränderbaren Vektors iterieren, um Änderungen an allen Elementen vorzunehmen. Die for-Schleife in Codeblock 8-8 addiert zu jedem Element 50.

#![allow(unused)]
fn main() {
let mut v = vec![100, 32, 57];
for i in &mut v {
    *i += 50;
}
}

Codeblock 8-8: Iterieren über veränderbare Referenzen der Elemente eines Vektors

Um den Wert, auf den sich die veränderbare Referenz bezieht, zu ändern, müssen wir den Dereferenzierungsoperator (*) verwenden, um an den Wert in i zu kommen, bevor wir den Operator += verwenden können. Wir werden mehr über den Dereferenzierungsoperator im Abschnitt „Dem Zeiger zum Wert folgen“ in Kapitel 15 sprechen.

Die Iteration über einen Vektor, ob unveränderbar oder veränderbar, ist aufgrund der Regeln des Ausleihenprüfers sicher. Wenn wir versuchen würden, Elemente in den for-Schleifenrümpfen in Codeblock 8-7 und Codeblock 8-8 einzufügen oder zu entfernen, würden wir einen Compilerfehler erhalten, ähnlich dem, den wir mit dem Code in Codeblock 8-6 erhalten haben. Die Referenz auf den Vektor, den die for-Schleife enthält, verhindert eine gleichzeitige Änderung des gesamten Vektors.

Verwenden einer Aufzählung zum Speichern mehrerer Typen

Vektoren können nur Werte desselben Typs speichern. Das kann unbequem sein; es gibt definitiv Anwendungsfälle, in denen es notwendig ist, eine Liste von Einträgen unterschiedlicher Typen zu speichern. Glücklicherweise werden die Varianten einer Aufzählung unter dem gleichen Aufzählungstyp definiert. Wenn wir also Elemente eines anderen Typs in einem Vektor speichern wollen, können wir eine Aufzählung definieren und verwenden!

Angenommen, wir möchten Werte aus einer Zeile einer Tabellenkalkulationstabelle erhalten, in der einige Spalten der Zeile ganze Zahlen, Fließkommazahlen und Zeichenketten enthalten. Wir können eine Aufzählung definieren, deren Varianten die verschiedenen Werttypen enthalten, und alle Aufzählungsvarianten werden als derselbe Typ angesehen: Der Typ der Aufzählung. Dann können wir einen Vektor erstellen, der diese Aufzählung und damit letztlich verschiedene Typen enthält. Wir haben dies in Codeblock 8-9 demonstriert.

#![allow(unused)]
fn main() {
enum SpreadsheetCell {
    Int(i32),
    Float(f64),
    Text(String),
}

let row = vec![
    SpreadsheetCell::Int(3),
    SpreadsheetCell::Text(String::from("blau")),
    SpreadsheetCell::Float(10.12),
];
}

Codeblock 8-9: Definieren eines enum, um Werte verschiedener Typen in einem Vektor zu speichern

Rust muss wissen, welche Typen zur Kompilierzeit im Vektor enthalten sein werden, damit es genau weiß, wie viel Speicherplatz im Haldenspeicher benötigt wird, um alle Elemente zu speichern. Wir müssen auch eindeutig festlegen, welche Typen in diesem Vektor zulässig sind. Wenn Rust einen Vektor mit beliebigen Typen zuließe, bestünde die Möglichkeit, dass einer oder mehrere Typen Fehler bei den an den Elementen des Vektors durchgeführten Operationen verursachen würden. Das Verwenden einer Aufzählung zusammen mit einem match-Ausdruck bedeutet, dass Rust zur Kompilierzeit sicherstellt, dass jeder mögliche Fall behandelt wird, wie in Kapitel 6 besprochen.

Wenn du nicht weißt, welche Typen ein Programm zur Laufzeit in einem Vektor speichern kann, funktioniert der Aufzählungsansatz nicht. Stattdessen kannst du ein Merkmalsobjekt (trait object) verwenden, das wir in Kapitel 17 behandeln werden.

Nachdem wir nun einige der gängigsten Methoden zur Verwendung von Vektoren besprochen haben, solltest du dir unbedingt die API-Dokumentation zu den vielen nützlichen Methoden ansehen, die die Standardbibliothek für Vec<T> mitbringt. Zum Beispiel gibt es zusätzlich zu push die Methode pop, die das letzte Element entfernt und zurückgibt.

Beim Aufräumen eines Vektors werden seine Elemente aufgeräumt

Wie bei jeder anderen Struktur wird ein Vektor freigegeben, wenn er den Gültigkeitsbereich verlässt, wie in Codeblock 8-10 kommentiert wird.

#![allow(unused)]
fn main() {
{
    let v = vec![1, 2, 3, 4];

    // mache etwas mit v
} // <- v verlässt den Gültigkeitsbereich und wird hier aufgeräumt
}

Codeblock 8-10: Zeigt, wo der Vektor und seine Elemente aufgeräumt werden

Wenn der Vektor aufgeräumt wird, wird auch sein gesamter Inhalt aufgeräumt, d.h. die ganzen Zahlen, die er enthält, werden beseitigt. Der Ausleihenprüfer stellt sicher, dass alle Referenzen auf den Inhalt eines Vektors nur verwendet werden, solange der Vektor selbst gültig ist.

Lass uns zum nächsten Kollektionstyp übergehen: String!

UTF-8-kodierten Text in Zeichenketten (strings) ablegen

Wir haben in Kapitel 4 über Zeichenketten (strings) gesprochen, aber wir werden uns jetzt eingehender damit befassen. Neue Rust-Entwickler haben gewöhnlich aus einer Kombination von drei Gründen Probleme mit Zeichenketten: Rusts Neigung, mögliche Fehler aufzudecken, Zeichenketten als eine kompliziertere Datenstruktur, als viele Programmierer ihnen zugestehen, und UTF-8. Diese Faktoren kombinieren sich in einer Weise, die schwierig erscheinen kann, wenn man von anderen Programmiersprachen kommt.

Wir besprechen Zeichenketten im Kontext von Kollektionen, da Zeichenketten als Byte-Kollektion implementiert sind, sowie einige Methoden, die nützliche Funktionalitäten bieten, wenn diese Bytes als Text interpretiert werden. In diesem Abschnitt werden wir über String-Operationen sprechen, die jeder Kollektionstyp hat, wie das Erstellen, Aktualisieren und Lesen. Wir werden auch die Art und Weise besprechen, in der sich String von den anderen Kollektionen unterscheidet, nämlich warum die Indexierung bei einem String kompliziert ist, weil Menschen und Computer String-Daten unterschiedlich interpretieren.

Was ist eine Zeichenkette?

Zuerst werden wir definieren, was wir mit dem Begriff Zeichenkette (string) meinen. Rust hat nur einen einzigen Zeichenkettentyp in der Kernsprache, nämlich den Zeichenkettenanteilstyp str, der üblicherweise in seiner Ausleihenform &str zu sehen ist. In Kapitel 4 sprachen wir über Zeichenkettenanteilstypen (string slices), die Referenzen auf einige UTF-8-kodierte Zeichenkettendaten sind, die anderswo gespeichert sind. Zeichenkettenliterale werden beispielsweise in der Binärdatei des Programms gespeichert und sind daher Zeichenkettenanteilstypen.

Der Typ String, der von Rusts Standardbibliothek zur Verfügung gestellt wird und nicht in die Kernsprache kodiert ist, ist ein größenänderbarer, veränderbarer, aneigenbarer, UTF-8-kodierter Zeichenkettentyp. Wenn Rust-Entwickler von Zeichenketten in Rust sprechen, meinen sie normalerweise den Typ String sowie den Zeichenkettenanteilstyp &str, nicht nur einen dieser Typen. Obwohl es in diesem Abschnitt weitgehend um String geht, werden beide Typen in Rusts Standardbibliothek stark verwendet, und sowohl String als auch Zeichenkettenanteilstypen sind UTF-8-kodiert.

Erstellen einer neuen Zeichenkette

Viele der gleichen Operationen, die mit Vec<T> verfügbar sind, sind auch mit String verfügbar, weil String eigentlich als Hülle um einen Vektor von Bytes mit einigen zusätzlichen Garantien, Einschränkungen und Fähigkeiten implementiert ist. Ein Beispiel für eine Funktion, die auf die gleiche Weise mit Vec<T> und String arbeitet, ist die Funktion new zum Erstellen einer Instanz, die in Codeblock 8-11 gezeigt wird.

#![allow(unused)]
fn main() {
let mut s = String::new();
}

Codeblock 8-11: Erstellen einer neuen, leeren Zeichenkette

Diese Zeile erzeugt eine neue, leere Zeichenkette namens s, in die wir dann Daten aufnehmen können. Oft werden wir einige initiale Daten haben, mit denen wir die Zeichenkette füllen wollen. Dazu verwenden wir die Methode to_string, die für jeden Typ verfügbar ist, der das Merkmal Display implementiert, wie es bei Zeichenkettenliteralen der Fall ist. Codeblock 8-12 zeigt zwei Beispiele.

#![allow(unused)]
fn main() {
let data = "initialer Inhalt";

let s = data.to_string();

// die Methode funktioniert auch direkt für ein Literal:
let s = "initialer Inhalt".to_string();
}

Codeblock 8-12: Verwenden der Methode to_string zum Erzeugen eines String aus einem Zeichenkettenliteral

Dieser Code erzeugt eine Zeichenkette, die initialer Inhalt enthält.

Wir können auch die Funktion String::from verwenden, um einen String aus einem Zeichenkettenliteral zu erzeugen. Der Code in Codeblock 8-13 ist äquivalent zum Code in Codeblock 8-12, der to_string verwendet.

#![allow(unused)]
fn main() {
let s = String::from("initialer Inhalt");
}

Codeblock 8-13: Verwenden der Funktion String::from zum Erzeugen eines String aus einem Zeichenkettenliteral

Da Zeichenketten für so viele Dinge verwendet werden, können wir viele verschiedene generische Programmierschnittstellen (APIs) für Zeichenketten verwenden, was uns viele Möglichkeiten bietet. Einige von ihnen können überflüssig erscheinen, aber sie alle haben ihren Platz! In diesem Fall machen String::from und to_string dasselbe, also ist die Wahl eine Frage des Stils und der Lesbarkeit.

Denke daran, dass Zeichenketten UTF-8-kodiert sind, sodass sie alle ordnungsgemäß kodierten Daten aufnehmen können, wie in Codeblock 8-14 gezeigt.

#![allow(unused)]
fn main() {
let hello = String::from("السلام عليكم");
let hello = String::from("Dobrý den");
let hello = String::from("Hallo");
let hello = String::from("Hello");
let hello = String::from("שָׁלוֹם");
let hello = String::from("नमस्ते");
let hello = String::from("こんにちは");
let hello = String::from("안녕하세요");
let hello = String::from("你好");
let hello = String::from("Olá");
let hello = String::from("Здравствуйте");
let hello = String::from("Hola");
}

Codeblock 8-14: Speichern von Begrüßungstexten in verschiedenen Sprachen in Zeichenketten

All dies sind gültige String-Werte.

Aktualisieren einer Zeichenkette

Ein String kann an Größe zunehmen und sein Inhalt kann sich ändern, genau wie der Inhalt eines Vec<T>, wenn du mehr Daten hineinschiebst. Darüber hinaus kannst du bequem den Operator + oder das Makro format! verwenden, um String-Werte aneinanderzuhängen.

Anhängen an eine Zeichenkette mit push_str und push

Wir können einen String wachsen lassen, indem wir die Methode push_str verwenden, um einen Zeichenkettenanteilstyp anzuhängen, wie in Codeblock 8-15 zu sehen ist.

#![allow(unused)]
fn main() {
let mut s = String::from("foo");
s.push_str("bar");
}

Codeblock 8-15: Anhängen eines Zeichenkettenanteilstyps an einen String mit der Methode push_str

Nach diesen beiden Zeilen enthält s den Wert foobar. Die Methode push_str nimmt einen Zeichenkettenanteilstyp, weil wir nicht unbedingt die Eigentümerschaft des Parameters übernehmen wollen. Zum Beispiel wollen wir im Code in Codeblock 8-16 in der Lage sein, s2 zu verwenden, nachdem wir seinen Inhalt an s1 angehängt haben.

#![allow(unused)]
fn main() {
let mut s1 = String::from("foo");
let s2 = "bar";
s1.push_str(s2);
println!("s2 ist {s2}");
}

Codeblock 8-16: Verwenden eines Zeichenkettenanteilstyps nach dem Anhängen seines Inhalts an eine Zeichenkette

Wenn die Methode push_str die Eigentümerschaft von s2 übernehmen würde, könnten wir ihren Wert nicht in der letzten Zeile ausgeben. Dieser Code funktioniert jedoch wie erwartet!

Die Methode push nimmt ein einzelnes Zeichen als Parameter und fügt es dem String hinzu. Codeblock 8-17 fügt den Buchstaben l mit der Methode push zu einem String hinzu.

#![allow(unused)]
fn main() {
let mut s = String::from("lo");
s.push('l');
}

Codeblock 8-17: Hinzufügen eines Zeichens zu einem String-Wert mit push

Als Ergebnis wird s den Wert lol enthalten.

Aneinanderhängen mit dem Operator + und dem Makro format!

Häufig möchtest du zwei vorhandene Zeichenketten kombinieren. Eine Möglichkeit das zu tun ist, den Operator + zu verwenden, wie in Codeblock 8-18 gezeigt.

#![allow(unused)]
fn main() {
let s1 = String::from("Hallo ");
let s2 = String::from("Welt!");
let s3 = s1 + &s2; // Beachte, s1 wurde hierher verschoben und
                   // kann nicht mehr verwendet werden
}

Codeblock 8-18: Verwenden des Operators +, um zwei Zeichenketten zu einer neuen zu kombinieren

Die Zeichenkette s3 wird Hallo Welt! enthalten. Der Grund, warum s1 nach der Addition nicht mehr gültig ist und warum wir eine Referenz auf s2 verwendet haben, hat mit der Signatur der Methode zu tun, die aufgerufen wird, wenn wir den Operator + verwenden. Der Operator + benutzt die Methode add, deren Signatur ungefähr so aussieht:

fn add(self, s: &str) -> String {

In der Standardbibliothek wird add mittels generischer Datentypen und assoziierter Typen definiert. Hier haben wir konkrete Typen ersetzt, was geschieht, wenn wir diese Methode mit String-Werten aufrufen. Wir werden generische Datentypen in Kapitel 10 besprechen. Diese Signatur gibt uns den entscheidenden Hinweis, um die kniffligen Stellen des Operators + zu verstehen.

Erstens hat s2 ein &, was bedeutet, dass wir eine Referenz der zweiten Zeichenkette an die erste Zeichenkette anhängen. Der Grund dafür ist der Parameter s in der Funktion add: Wir können nur einen &str zu einem String hinzufügen; wir können nicht zwei String-Werte aneinanderhängen. Aber warte – der Typ von &s2 ist &String, nicht &str, wie im zweiten Parameter von add spezifiziert. Warum kompiliert also Codeblock 8-18?

Der Grund, warum wir &s2 im Aufruf von add verwenden können, ist, dass der Compiler das Argument &String in einen &str umwandeln (coerce) kann. Wenn wir die Methode add aufrufen, benutzt Rust eine automatische Umwandlung (deref coercion), die hier &s2 in &s2[...] umwandelt. Auf die automatische Umwandlung werden wir in Kapitel 15 tiefer eingehen. Da add nicht die Eigentümerschaft des Parameters s übernimmt, ist s2 auch nach dieser Operation immer noch ein gültiger String.

Zweitens können wir in der Signatur sehen, dass add die Eigentümerschaft von self übernimmt, weil self kein & hat. Das bedeutet, dass s1 in Codeblock 8-18 in den Aufruf von add verschoben wird und danach nicht mehr gültig ist. Obwohl also let s3 = s1 + &s2; so aussieht, als ob beide Zeichenketten kopiert und eine neue erzeugt wird, übernimmt diese Anweisung tatsächlich die Eigentümerschaft von s1, hängt eine Kopie des Inhalts von s2 an und gibt dann die Eigentümerschaft des Ergebnisses zurück. In anderen Worten sieht es so aus, als würde es viele Kopien erstellen, das ist aber nicht so; die Implementierung ist effizienter als Kopieren.

Wenn wir mehrere Zeichenketten aneinanderhängen wollen, wird das Verhalten des Operators + unhandlich:

#![allow(unused)]
fn main() {
let s1 = String::from("tic");
let s2 = String::from("tac");
let s3 = String::from("toe");

let s = s1 + "-" + &s2 + "-" + &s3;
}

An diesem Punkt wird s den Wert tic-tac-toe haben. Bei all den Zeichen + und " ist es schwer zu erkennen, was vor sich geht. Für kompliziertere String-Kombinationen können wir stattdessen das Makro format! verwenden:

#![allow(unused)]
fn main() {
let s1 = String::from("tic");
let s2 = String::from("tac");
let s3 = String::from("toe");

let s = format!("{s1}-{s2}-{s3}");
}

Auch bei diesem Code wird s den Wert tic-tac-toe haben. Das Makro format! funktioniert wie println!, aber anstatt das Ergebnis auf den Bildschirm auszugeben, gibt es einen String mit dem Inhalt zurück. Die Codevariante mit format! ist viel leichter lesbar, und der durch das Makro format! erzeugte Code verwendet Referenzen, sodass dieser Aufruf keine Eigentümerschaft seiner Parameter übernimmt.

Indexierung von Zeichenketten

In vielen anderen Programmiersprachen ist das Zugreifen auf einzelne Zeichen in einer Zeichenkette mittels Index eine gültige und gängige Operation. Wenn du jedoch in Rust versuchst, mittels Indexierungssyntax auf Teile einer Zeichenkette zuzugreifen, wirst du einen Fehler erhalten. Betrachte den ungültigen Code in Codeblock 8-19.

#![allow(unused)]
fn main() {
let s1 = String::from("Hallo");
let h = s1[0];
}

Codeblock 8-19: Versuch, die Indexierungssyntax bei einer Zeichenkette zu verwenden

Dieser Code führt zu folgendem Fehler:

$ cargo run
   Compiling collections v0.1.0 (file:///projects/collections)
error[E0277]: the type `String` cannot be indexed by `{integer}`
 --> src/main.rs:3:16
  |
3 |     let h = s1[0];
  |                ^ `String` cannot be indexed by `{integer}`
  |
  = help: the trait `Index<{integer}>` is not implemented for `String`
  = help: the following other types implement trait `Index<Idx>`:
            <String as Index<RangeFull>>
            <String as Index<std::ops::Range<usize>>>
            <String as Index<RangeFrom<usize>>>
            <String as Index<RangeTo<usize>>>
            <String as Index<RangeInclusive<usize>>>
            <String as Index<RangeToInclusive<usize>>>

For more information about this error, try `rustc --explain E0277`.
error: could not compile `collections` (bin "collections") due to 1 previous error

Die Fehlermeldung und der Hinweis erzählen die Geschichte: Zeichenketten in Rust unterstützen keine Indexierung. Aber warum nicht? Um diese Frage zu beantworten, müssen wir uns ansehen, wie Rust Zeichenketten im Speicher ablegt.

Interne Darstellung

Ein String ist eine Hülle um einen Vec<u8>. Sehen wir uns einige unserer korrekt kodierten UTF-8-Beispielzeichenketten aus Codeblock 8-14 an. Zuerst diese:

#![allow(unused)]
fn main() {
let hello = String::from("Hola");
}

In diesem Fall wird hello.len() gleich 4 sein, was bedeutet, dass der Vektor, der die Zeichenkette „Hola“ speichert, 4 Bytes lang ist. Jeder dieser Buchstaben benötigt 1 Byte in UTF-8-Kodierung. Die folgende Zeile mag dich jedoch überraschen. (Beachte, dass diese Zeichenkette mit dem kyrillischen Großbuchstaben „Ze“ beginnt, nicht mit der Zahl 3.)

#![allow(unused)]
fn main() {
let hello = String::from("Здравствуйте");
}

Auf die Frage, wie lang die Zeichenkette ist, könnte man sagen: 12. Die Antwort von Rust lautet jedoch 24: Das ist die Anzahl der Bytes, die benötigt wird, um „Здравствуйте“ in UTF-8 zu kodieren, da jeder Unicode-Skalarwert in dieser Zeichenkette 2 Bytes Speicherplatz benötigt. Daher wird ein Index auf die Bytes der Zeichenkette nicht immer mit einem gültigen Unicode-Skalarwert korrelieren. Um das zu erläutern, betrachte diesen ungültigen Rust-Code:

#![allow(unused)]
fn main() {
let hello = "Здравствуйте";
let answer = &hello[0];
}

Du weißt bereits, dass answer nicht З, der erste Buchstabe, sein wird. In der UTF-8-Kodierung von З ist das erste Byte 208 und das zweite 151, sodass answer eigentlich 208 sein müsste, aber 208 ist kein eigenständig gültiges Zeichen. Die Rückgabe von 208 ist wahrscheinlich nicht das, was ein Nutzer wünschen würde, wenn er nach dem ersten Buchstaben dieser Zeichenkette fragte; das sind jedoch die einzigen Daten, die Rust beim Byte-Index 0 hat. Nutzer wollen im Allgemeinen nicht, dass der Byte-Wert zurückgegeben wird, selbst wenn die Zeichenkette nur lateinische Buchstaben enthält: Wenn &"hallo"[0] gültiger Code wäre, der den Byte-Wert zurückgibt, würde er 104 zurückgeben, nicht h.

Um zu vermeiden, dass ein unerwarteter Wert zurückgegeben wird und dadurch Fehler entstehen, die möglicherweise nicht sofort entdeckt werden, kompiliert Rust diesen Code überhaupt nicht und verhindert so Missverständnisse in einem frühen Stadium des Entwicklungsprozesses.

Bytes, skalare Werte und Graphemgruppen (grapheme clusters)! Oje!

Ein weiterer Punkt bei UTF-8 ist, dass es eigentlich drei relevante Möglichkeiten gibt, Zeichenketten aus Rusts Perspektive zu betrachten: Als Bytes, als skalare Werte und als Graphemgruppen (das, was wir am ehesten als Buchstaben bezeichnen würden).

Wenn wir uns das in der Devanagari-Schrift geschriebene Hindi-Wort „नमस्ते“ (Namaste) ansehen, wird es als ein Vektor von u8-Werten gespeichert, der wie folgt aussieht:

[224, 164, 168, 224, 164, 174, 224, 164, 184, 224, 165, 141, 224, 164, 164,
224, 165, 135]

Das sind 18 Bytes, so wie ein Computer diese Daten letztendlich speichert. Wenn wir sie als Unicode-Skalarwerte betrachten, also als das, was der Typ char in Rust ist, sehen diese Bytes wie folgt aus:

['न', 'म', 'स', '्', 'त', 'े']

Es gibt hier sechs char-Werte, aber der vierte und der sechste sind keine Buchstaben: Sie sind diakritische Zeichen, die für sich allein genommen keinen Sinn ergeben. Wenn wir sie schließlich als Graphemgruppen betrachten, erhalten wir das, was eine Person die vier Buchstaben nennen würde, aus denen das Hindi-Wort besteht:

["न", "म", "स्", "ते"]

Rust bietet verschiedene Möglichkeiten zur Interpretation von rohen Zeichenkettendaten, die von Computern gespeichert werden, sodass jedes Programm die Interpretation wählen kann, die es benötigt, unabhängig davon, in welcher menschlichen Sprache die Daten vorliegen.

Ein letzter Grund, warum Rust uns nicht erlaubt, eine Zeichenkette zu indexieren, um ein Zeichen zu erhalten, ist, dass von Indexoperationen erwartet wird, dass sie immer in konstanter Zeit (O(1)) erfolgen. Es ist jedoch nicht möglich, diese Zeitgarantie bei einem String einzuhalten, da Rust den Inhalt von Anfang an bis zum Index durchgehen müsste, um festzustellen, wie viele gültige Zeichen es gibt.

Anteilige Zeichenketten

Die Indexierung einer Zeichenkette ist oft eine schlechte Idee, weil nicht klar ist, was der Rückgabetyp der Zeichenketten-Indexoperation sein soll: Ein Byte-Wert, ein Zeichen, eine Graphemgruppe oder ein Zeichenkettenanteilstyp. Wenn du wirklich Indizes verwenden musst, um Zeichenkettenanteilstypen zu erstellen, bittet Rust dich daher, genauer zu sein.

Anstatt [] mit einer einzelnen Zahl zu indizieren, kannst du [] mit einem Bereich verwenden, um ein Zeichenkettenanteilstyp zu erstellen, der bestimmte Bytes enthält:

#![allow(unused)]
fn main() {
let hello = "Здравствуйте";

let s = &hello[0..4];
}

Hier wird s ein &str sein, das die ersten 4 Bytes der Zeichenkette enthält. Vorhin haben wir bereits erwähnt, dass jedes dieser Zeichen 2 Bytes lang ist, was bedeutet, dass s gleich Зд ist.

Wenn wir versuchen würden, nur einen Teil der Bytes eines Zeichens mit etwas wie &hello[0..1] zu zerschneiden, würde Rust das Programm zur Laufzeit abbrechen, genauso als wenn mit einem ungültigen Index auf einen Vektor zugegriffen würde:

$ cargo run
   Compiling collections v0.1.0 (file:///projects/collections)
    Finished dev [unoptimized + debuginfo] target(s) in 0.43s
     Running `target/debug/collections`
thread 'main' panicked at src/main.rs:4:19:
byte index 1 is not a char boundary; it is inside 'З' (bytes 0..2) of `Здравствуйте`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Bei der Verwendung von Bereichen zum Erstellen von Zeichenkettenanteilstypen ist Vorsicht geboten, da dies zum Absturz deines Programms führen kann.

Methoden zum Iterieren über Zeichenketten

Der beste Weg, um mit Teilen von Zeichenketten zu arbeiten, besteht darin, explizit anzugeben, ob du Zeichen oder Bytes benötigst. Für einzelne Unicode-Skalarwerte ist die Methode chars zu verwenden. Der Aufruf von chars auf „Зд“ trennt zwei Werte vom Typ char heraus und gibt sie zurück, und du kannst über das Ergebnis iterieren, um auf jedes Element zuzugreifen:

#![allow(unused)]
fn main() {
for c in "Зд".chars() {
    println!("{c}");
}
}

Dieser Code wird folgendes ausgeben:

З
д

Die Methode bytes gibt jedes rohe Byte zurück, das für deinen Verwendungszweck benötigt wird:

#![allow(unused)]
fn main() {
for b in "Зд".bytes() {
    println!("{b}");
}
}

Dieser Code gibt die vier Bytes aus, aus denen diese Zeichenkette besteht:

208
151
208
180

Aber denke daran, dass gültige Unicode-Skalarwerte aus mehr als 1 Byte bestehen können.

Die Ermittlung von Graphemgruppen aus Zeichenketten wie bei der Devanagari-Schrift ist komplex, sodass diese Funktionalität nicht von der Standardbibliothek bereitgestellt wird. Kisten (crates) sind unter crates.io verfügbar, falls du diese Funktionalität benötigst.

Zeichenketten sind nicht so einfach

Zusammenfassend kann man sagen, dass Zeichenketten kompliziert sind. Verschiedene Programmiersprachen treffen unterschiedliche Entscheidungen darüber, wie diese Komplexität dem Programmierer angezeigt wird. Rust hat sich dafür entschieden, den korrekten Umgang mit Zeichenkettendaten zum Standardverhalten für alle Rust-Programme zu machen, was bedeutet, dass Programmierer sich im Vorfeld mehr Gedanken über den Umgang mit UTF-8-Daten machen müssen. Dieser Zielkonflikt macht die Komplexität von Zeichenketten größer als in anderen Programmiersprachen, aber er verhindert, dass du später in deinem Entwicklungslebenszyklus mit Fehlern umgehen musst, wenn Nicht-ASCII-Zeichen vorkommen.

Die gute Nachricht ist, dass die Standardbibliothek eine Vielzahl von Funktionen bietet, die auf den Typen String und &str aufbauen, um diese komplexen Situationen korrekt zu behandeln. In der Dokumentation findest du nützliche Methoden wie contains zum Suchen in einer Zeichenkette und replace zum Ersetzen von Teilen einer Zeichenkette durch eine andere Zeichenkette.

Lass uns zu etwas weniger Kompliziertem übergehen: Hashtabellen!

Schlüssel mit zugehörigen Werten in Hashtabellen ablegen

Die letzte unserer allgemeinen Kollektionen ist die Hashtabelle (hash map). Der Typ HashMap<K, V> speichert eine Zuordnung von Schlüsseln vom Typ K zu Werten vom Typ V mittels einer Hashfunktion (hash function), die bestimmt, wie er diese Schlüssel und Werte im Speicher ablegt. Viele Programmiersprachen unterstützen diese Art Datenstruktur, aber sie verwenden oft einen anderen Namen, z.B. Hash, Abbildung (map), Objekt, Hashtabelle (hash table), Wörterbuch (dictionary) oder assoziatives Array (associative array), um nur einige zu nennen.

Hashtabellen sind nützlich, wenn du Daten nicht wie bei Vektoren über einen Index nachschlagen willst, sondern über einen Schlüssel, der ein beliebiger Typ sein kann. Beispielsweise könntest du in einem Spiel den Spielstand jedes Teams in einer Hashtabelle vermerken, in der die Schlüssel den Teamnamen und die Werte den Spielstand des jeweiligen Teams darstellen. Wenn du den Namen eines Teams angibst, kannst du seine Punktzahl abrufen.

In diesem Abschnitt gehen wir die grundlegende Programmierschnittstelle (API) von Hashtabellen durch, aber viele weitere Leckerbissen verbergen sich in den Funktionen, die in der Standardbibliothek für HashMap<K, V> definiert sind. Weitere Informationen findest du wie immer in der Standardbibliotheksdokumentation.

Erstellen einer neuen Hashtabelle

Ein Weg um eine leere Hashtabelle zu erzeugen ist mit new und um Elemente hinzuzufügen mit insert. In Codeblock 8-20 verfolgen wir die Ergebnisse zweier Mannschaften mit den Namen Blau und Gelb. Das Team Blau startet mit 10 Punkten, das Team Gelb mit 50 Punkten.

#![allow(unused)]
fn main() {
use std::collections::HashMap;

let mut scores = HashMap::new();

scores.insert(String::from("Blau"), 10);
scores.insert(String::from("Gelb"), 50);
}

Codeblock 8-20: Erstellen einer neuen Hashtabelle und Einfügen einiger Schlüssel und Werte

Beachte, dass wir zuerst mit use die HashMap aus dem Kollektionsteil der Standardbibliothek einbinden müssen. Von unseren drei allgemeinen Kollektionen wird diese am seltensten verwendet, sodass sie nicht zu den Funktionalitäten gehört, die automatisch in den Gültigkeitsbereich aufgenommen werden. Hashtabellen werden auch weniger von der Standardbibliothek unterstützt; es gibt zum Beispiel kein eingebautes Makro, um sie zu erzeugen.

Genau wie Vektoren speichern Hashtabellen ihre Daten im Haldenspeicher. Obige HashMap hat Schlüssel vom Typ String und Werte vom Typ i32. Hashtabellen sind wie Vektoren homogen: Alle Schlüssel müssen denselben Typ haben und alle Werte müssen denselben Typ haben.

Zugreifen auf Werte in einer Hashtabelle

Wir können einen Wert aus der Hashtabelle herausholen, indem wir die Methode get mit ihrem Schlüssel aufrufen, wie in Codeblock 8-21 gezeigt.

#![allow(unused)]
fn main() {
use std::collections::HashMap;

let mut scores = HashMap::new();

scores.insert(String::from("Blau"), 10);
scores.insert(String::from("Gelb"), 50);

let team_name = String::from("Blau");
let score = scores.get(&team_name).copied().unwrap_or(0);
}

Codeblock 8-21: Zugreifen auf den Spielstand von Team Blau in der Hashtabelle

Hier wird score den Wert haben, der mit Team Blau assoziiert ist, und das Ergebnis wird 10 sein. Die Methode get gibt eine Option<&V> zurück; wenn es keinen Wert für diesen Schlüssel in der Hashtabelle gibt, gibt get den Wert None zurück. Dieses Programm behandelt die Option, indem es copied aufruft, um eine Option<i32> anstelle einer Option<&i32> zu erhalten, und ruft dann unwrap_or auf, um score auf Null zu setzen, wenn scores keinen Eintrag für den Schlüssel hat.

Wir können über jedes Schlüssel-Wert-Paar in einer Hashtabelle auf ähnliche Weise iterieren wie bei Vektoren, indem wir eine for-Schleife verwenden:

#![allow(unused)]
fn main() {
use std::collections::HashMap;

let mut scores = HashMap::new();

scores.insert(String::from("Blau"), 10);
scores.insert(String::from("Gelb"), 50);

for (key, value) in &scores {
    println!("{key}: {value}");
}
}

Dieser Code gibt alle Paare in einer beliebigen Reihenfolge aus:

Gelb: 50
Blau: 10

Hashtabellen und Eigentümerschaft

Bei Typen wie i32, die das Merkmal Copy implementieren, werden die Werte in die Hashtabelle kopiert. Bei aneigenbaren Werten wie String werden die Werte verschoben und die Hashtabelle ist Eigentümer dieser Werte, wie in Codeblock 8-22 gezeigt wird.

#![allow(unused)]
fn main() {
use std::collections::HashMap;

let field_name = String::from("Lieblingsfarbe");
let field_value = String::from("Blau");

let mut map = HashMap::new();
map.insert(field_name, field_value);
// field_name und field_value sind nach diesem Zeitpunkt ungültig.
// Versuche, sie zu benutzen und beobachte, welchen Kompilierfehler du erhältst!
}

Codeblock 8-22: Zeigt, dass Schlüssel und Werte nach dem Aufruf von insert Eigentum der Hashtabelle sind

Wir können die Variablen field_name und field_value nicht mehr verwenden, nachdem sie mit dem Aufruf von insert in die Hashtabelle verschoben wurden.

Wenn wir Referenzen auf Werte in die Hashtabelle einfügen, werden die Werte nicht in die Hashtabelle verschoben. Die Werte, auf die die Referenzen zeigen, müssen mindestens so lange gültig sein, wie die Hashtabelle gültig ist. Wir werden mehr über diese Fragen im Abschnitt „Referenzen validieren mit Lebensdauern“ in Kapitel 10 sprechen.

Aktualisieren einer Hashtabelle

Obwohl die Anzahl der Schlüssel- und Wertepaare vergrößerbar ist, kann jedem eindeutigen Schlüssel jeweils nur ein Wert zugeordnet werden (aber nicht umgekehrt: Zum Beispiel könnten sowohl das blaue Team als auch das gelbe Team den Wert 10 in der Hashtabelle scores gespeichert haben).

Wenn du die Daten in einer Hashtabelle ändern willst, musst du entscheiden, wie der Fall zu behandeln ist, wenn einem Schlüssel bereits ein Wert zugewiesen wurde. Du kannst den alten Wert durch den neuen ersetzen und dabei den alten Wert völlig außer Acht lassen. Du kannst den alten Wert behalten und den neuen Wert ignorieren und nur dann den neuen Wert hinzufügen, wenn der Schlüssel noch keinen zugewiesenen Wert hat. Oder du kannst den alten und neuen Wert kombinieren. Schauen wir uns an, wie diese Varianten jeweils funktionieren!

Überschreiben eines Wertes

Wenn wir einen Schlüssel und einen Wert in eine Hashtabelle einfügen und dann denselben Schlüssel mit einem anderen Wert einfügen, wird der mit diesem Schlüssel assoziierte Wert ersetzt. Auch wenn der Code in Codeblock 8-23 zweimal insert aufruft, wird die Hashtabelle nur ein Schlüssel-Wert-Paar enthalten, weil wir beide Male einen Wert für den Schlüssel des Teams Blau einfügen.

#![allow(unused)]
fn main() {
use std::collections::HashMap;

let mut scores = HashMap::new();

scores.insert(String::from("Blau"), 10);
scores.insert(String::from("Blau"), 25);

println!("{:?}", scores);
}

Codeblock 8-23: Ersetzen eines gespeicherten Wertes für einen bestimmten Schlüssel

Dieser Code wird {"Blau": 25} ausgeben. Der ursprüngliche Wert 10 wurde überschrieben.

Einen Schlüssel und Wert nur dann einfügen, wenn der Schlüssel nicht vorhanden ist

Es ist üblich, zu prüfen, ob ein bestimmter Schlüssel bereits in der Hashtabelle mit einem Wert vorhanden ist, und dann folgende Maßnahmen zu ergreifen: Wenn der Schlüssel in der Hashtabelle vorhanden ist, sollte der vorhandene Wert so bleiben, wie er ist. Wenn der Schlüssel nicht vorhanden ist, füge ihn und einen Wert für ihn ein.

Hashtabellen haben dafür eine spezielle Programmierschnittstelle (API) namens entry, die den Schlüssel, den du prüfen willst, als Parameter nimmt. Der Rückgabewert der Methode entry ist eine Aufzählung (enum) namens Entry, die einen Wert repräsentiert, der existieren könnte oder auch nicht. Nehmen wir an, wir wollen prüfen, ob der Schlüssel für das Team Gelb einen Wert hat. Wenn das nicht der Fall ist, wollen wir den Wert 50 einfügen, und dasselbe gilt für das Team Blau. Bei Verwendung von entry sieht der Code wie Codeblock 8-24 aus.

#![allow(unused)]
fn main() {
use std::collections::HashMap;

let mut scores = HashMap::new();
scores.insert(String::from("Blau"), 10);

scores.entry(String::from("Gelb")).or_insert(50);
scores.entry(String::from("Blau")).or_insert(50);

println!("{:?}", scores);
}

Codeblock 8-24: Verwenden der Methode entry zum Einfügen, nur wenn der Schlüssel nicht bereits einen Wert hat

Die Methode or_insert von Entry ist so definiert, dass sie eine veränderbare Referenz auf den Wert des entsprechenden Entry-Schlüssels zurückgibt, wenn dieser Schlüssel existiert, andernfalls fügt sie den Parameter als neuen Wert für diesen Schlüssel ein und gibt eine veränderbare Referenz auf den neuen Wert zurück. Diese Technik ist viel sauberer, als die Logik selbst zu schreiben, und sie harmoniert besser mit dem Ausleihenprüfer.

Der Code in Codeblock 8-24 gibt {"Gelb": 50, "Blau": 10} aus. Beim ersten Aufruf von entry wird der Schlüssel von Team Gelb mit dem Wert 50 eingefügt, da das Team Gelb noch keinen Wert hat. Der zweite Aufruf von entry wird die Hashtabelle nicht verändern, da das Team Blau bereits den Wert 10 hat.

Aktualisieren eines Wertes auf Basis des alten Wertes

Ein weiterer gängiger Anwendungsfall für Hashtabellen besteht darin, den Wert eines Schlüssels nachzuschlagen und ihn dann auf Basis des alten Wertes zu aktualisieren. Beispielsweise zeigt Codeblock 8-25 einen Code, der zählt, wie oft jedes Wort in einem Text vorkommt. Wir verwenden eine Hashtabelle mit den Wörtern als Schlüssel und inkrementieren den Wert, um nachzuvollziehen, wie oft wir dieses Wort schon gesehen haben. Wenn es das erste Mal ist, dass wir ein Wort sehen, fügen wir zuerst den Wert 0 ein.

#![allow(unused)]
fn main() {
use std::collections::HashMap;

let text = "Hallo Welt wunderbare Welt";

let mut map = HashMap::new();

for word in text.split_whitespace() {
    let count = map.entry(word).or_insert(0);
    *count += 1;
}

println!("{:?}", map);
}

Codeblock 8-25: Zählen des Vorkommens von Wörtern mit Hilfe einer Hashtabelle, die Wörter speichert und zählt

Dieser Code gibt {"Welt": 2, "wunderbare": 1, "Hallo": 1} aus. Es kann sein, dass dieselben Schlüssel/Wert-Paare in einer anderen Reihenfolge ausgegeben werden: Du erinnerst dich an den Abschnitt „Zugreifen auf Werte in einer Hashtabelle“, dass die Iteration über eine Hashtabelle in beliebiger Reihenfolge erfolgt.

Die Methode split_whitespace gibt einen Iterator über durch Leerzeichen getrennte Sub-Anteilstypen des Wertes in text zurück. Die Methode or_insert gibt eine veränderbare Referenz (&mut V) auf den Wert für den angegebenen Schlüssel zurück. Hier speichern wir diese veränderbaren Referenz in der Variablen count. Um diesen Wert zuzuweisen, müssen wir also zuerst count mit dem Stern (*) derefenzieren. Die veränderbare Referenz verlässt am Ende der for-Schleife dem Gültigkeitsbereich, sodass alle diese Änderungen sicher und gemäß der Ausleihregeln zulässig sind.

Hash-Funktionen

Standardmäßig verwendet HashMap eine Hash-Funktion namens SipHash, die robust gegen Denial-of-Service-Angriffe (DoS) mit Hash-Tabellen¹ ist. Dies ist nicht der schnellste verfügbare Hashing-Algorithmus, aber der Kompromiss zugunsten einer höheren Sicherheit gegenüber einer geringeren Performanz ist es Wert. Wenn du eine Performanzanalyse deines Codes machst und feststellst, dass die Standard-Hash-Funktion für deine Zwecke zu langsam ist, kannst du zu einer anderen Funktion wechseln, indem du eine andere Hash-Funktion angibst. Eine Hash-Funktion ist ein Typ, der das Merkmal BuildHasher implementiert. Wir werden in Kapitel 10 über Merkmale und ihre Implementierung sprechen. Du musst nicht unbedingt deine eigene Hash-Funktion von Grund auf implementieren; crates.io verfügt über Bibliotheken, die von anderen Rust-Nutzern bereitgestellt werden und viele gängige Hash-Funktionen implementieren.

Zusammenfassung

Vektoren, Zeichenketten und Hashtabellen bieten eine große Menge an Funktionalität, die in Programmen benötigt wird, wenn du Daten speichern, darauf zugreifen und sie verändern willst. Hier sind einige Übungen, für deren Lösung du jetzt gerüstet sein solltest:

• Verwende bei einer Liste von ganzen Zahlen einen Vektor und gib den Median (wenn sortiert, den Wert in der Mitte) und den Modus (den Wert, der am häufigsten vorkommt; eine Hashtabelle ist hier hilfreich) der Liste zurück.
• Wandle Zeichenketten in Schweinelatein (pig latin) um. Der erste Konsonant jedes Wortes wird an das Ende des Wortes verschoben und „ay“ angehängt, sodass „zuerst“ zu „uerst-zay“ wird. Bei Wörtern, die mit einem Vokal beginnen, wird stattdessen „hay“ an das Ende angefügt („ansehen“ wird zu „ansehen-hay“). Beachte die Details zur UTF-8-Kodierung!
• Erstelle mit Hilfe einer Hashtabelle und Vektoren eine Textschnittstelle, die es einem Benutzer ermöglicht, Mitarbeiternamen zu einer Abteilung in einem Unternehmen hinzuzufügen. Zum Beispiel „Sally zur Technik hinzufügen“ oder „Amir zum Vertrieb hinzufügen“. Lass den Benutzer dann eine alphabetisch sortierte Liste aller Personen in einer Abteilung oder aller Personen in der Firma nach Abteilung ausgeben.

Die API-Dokumentation der Standard-Bibliothek beschreibt Methoden für Vektoren, Zeichenketten und Hashtabellen, die für diese Übungen hilfreich sind!

Wir steigen in komplexere Programme ein, in denen Operationen fehlschlagen können, daher ist es ein perfekter Zeitpunkt, auf die Fehlerbehandlung einzugehen. Das werden wir als nächstes tun!

Fehlerbehandlung

Fehler sind eine Tatsache im Software-Alltag, deshalb enthält Rust eine Reihe von Funktionalitäten zur Behandlung von Situationen, in denen etwas schiefgeht. In vielen Fällen verlangt Rust von dir, dass du die Möglichkeit eines Fehlers anerkennst und Vorkehrungen ergreifst, damit dein Code kompiliert werden kann. Diese Anforderung macht dein Programm robuster, da sichergestellt wird, dass du Fehler entdeckst und diese angemessen behandelst, bevor dein Code in Produktion gebracht wird!

Rust gruppiert Fehler in zwei Hauptkategorien: Behebbare (recoverable) und nicht behebbare (unrecoverable) Fehler. Bei einem behebbaren Fehler, z.B. „Datei nicht gefunden“, wollen wir das Problem wahrscheinlich dem Benutzer melden und den Vorgang erneut versuchen. Nicht behebbare Fehler sind immer Symptome von Programmierfehlern, z.B. der Versuch, auf eine Stelle hinter dem Ende eines Arrays zuzugreifen, und deshalb wollen wir das Programm sofort anhalten.

Die meisten Sprachen unterscheiden nicht zwischen diesen beiden Fehlerarten und behandeln beide auf die gleiche Weise, indem sie Mechanismen wie die Ausnahmebehandlung verwenden. Rust hat keine Ausnahmebehandlung. Stattdessen hat es den Typ Result<T, E> für behebbare Fehler und das Makro panic!, das die Ausführung stoppt, wenn das Programm auf einen nicht behebbaren Fehler stößt. Dieses Kapitel behandelt zuerst das Aufrufen von panic! und spricht dann über die Rückgabe von Result<T, E>-Werten. Darüber hinaus werden wir uns mit der Frage befassen, wann man versuchen sollte, einen Fehler zu beheben oder die Ausführung zu stoppen.

Nicht behebbare Fehler mit panic!

Manchmal passieren schlimme Dinge in deinem Code und du kannst nichts dagegen tun. Für diese Fälle hat Rust das Makro panic!. In der Praxis gibt es zwei Möglichkeiten, ein Programm abstürzen zu lassen: Durch eine Aktion, die unseren Code abstürzen lässt (z.B. Zugriff auf ein Array über das Ende hinaus) oder durch den expliziten Aufruf des Makros panic!. In beiden Fällen brechen wir unser Programm ab. Standardmäßig geben diese Programmabbrüche eine Fehlermeldung aus, räumen den Stapelspeicher auf und beenden sich. Über eine Umgebungsvariable kannst du auch festlegen, dass Rust den Stapelspeicher anzeigt, wenn das Programm abbricht, damit du die Quelle des Abbruchs leichter aufspüren kannst.

Auflösen des Stapelspeichers oder Abbrechen als Fehlerreaktion

Wenn ein Programmabbruch auftritt, beginnt das Programm standardmäßig mit dem Abwickeln, was bedeutet, dass Rust den Stapelspeicher wieder nach oben geht und die Daten aller Funktion aufräumt. Allerdings ist dieses Zurückgehen und Aufräumen eine Menge Arbeit. Rust bietet dir als Alternative daher an, das Programm sofort abzubrechen, also das Programm ohne Aufräumen zu beenden.

Der Speicher, den das Programm benutzt hat, muss dann vom Betriebssystem aufgeräumt werden. Wenn du in deinem Projekt die resultierende Binärdatei so klein wie möglich machen willst, kannst du für ein vorzeitiges Programmende vom Abwickeln zum sofortigen Abbrechen umschalten, indem du panic = 'abort' in den entsprechenden [profile]-Abschnitten in deiner Cargo.toml-Datei hinzufügst. Wenn du beispielsweise im Freigabemodus (release mode) im Fehlerfall sofort abbrechen möchtest, füge dies hinzu:

[profile.release]
panic = 'abort'

Versuchen wir panic! in einem einfachen Programm aufzurufen:

Dateiname: src/main.rs

fn main() {
    panic!("abstürzen und verbrennen");
}

Wenn du das Programm ausführst, wirst du in etwa das hier sehen:

$ cargo run
   Compiling panic v0.1.0 (file:///projects/panic)
    Finished dev [unoptimized + debuginfo] target(s) in 0.25s
     Running `target/debug/panic`
thread 'main' panicked at src/main.rs:2:5:
abstürzen und verbrennen
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Der Aufruf von panic! verursacht die in den letzten beiden Zeilen enthaltene Fehlermeldung. Die erste Zeile zeigt unsere Fehlermeldung und die Position in unserem Quellcode, an der der Fehler aufgetreten ist: src/main.rs:2:5 gibt an, dass es sich um die zweite Zeile und dem fünften Zeichen in unserer Datei src/main.rs handelt.

In diesem Fall ist die angegebene Zeile Teil unseres Codes und wenn wir uns diese Zeile ansehen, sehen wir den Makroaufruf panic!. In anderen Fällen könnte der Aufruf von panic! in Code erfolgen, den unser Code aufruft, und der Dateiname und die Zeilennummer in der Fehlermeldung gehören zu Code von jemand anderen, der das Makro panic! aufruft, nicht zu unserem Code, der schließlich zum Aufruf von panic! geführt hat. Wir können die Aufrufhistorie (backtrace) der Funktionen, von der der panic!-Aufruf kam, nutzen, um den Codeteil zu ermitteln, der das Problem verursacht. Wir werden Aufrufhistorien im nächsten Abschnitt ausführlicher besprechen.

Verwenden einer panic!-Aufrufhistorie

Sehen wir uns ein weiteres Beispiel an, bei dem der panic!-Aufruf von einer Bibliothek kommt, weil wir einen Fehler in unserem Code haben, anstatt das Makro direkt aufzurufen. Codeblock 9-1 enthält einen Code, der versucht, auf einen Index in einem Vektor zuzugreifen, der außerhalb des Bereichs gültiger Indizes liegt.

Dateiname: src/main.rs

fn main() {
    let v = vec![1, 2, 3];

    v[99];
}

Codeblock 9-1: Versuch, auf ein Element jenseits des Endes eines Vektors zuzugreifen, was einen Aufruf von panic! auslöst

Hier versuchen wir, auf das 100. Element unseres Vektors zuzugreifen (das bei Index 99 liegt, weil die Indexierung bei Null beginnt), der Vektor hat aber nur 3 Elemente. In dieser Situation wird Rust das Programm abbrechen. Das Verwenden von [] soll ein Element zurückgeben, aber wenn du einen ungültigen Index übergibst, gibt es kein Element, das Rust hier korrekterweise zurückgeben könnte.

In C ist der Versuch, über das Ende einer Datenstruktur hinaus zu lesen, ein undefiniertes Verhalten. Möglicherweise erhältst du den Wert im Speicher an der der Datenstruktur entsprechenden Stelle, selbst wenn der Speicher nicht zu dieser Struktur gehört. Dies wird als Hinauslesen über den Puffer (buffer overread) bezeichnet und kann zu Sicherheitslücken führen, wenn ein Angreifer in der Lage ist, den Index so zu manipulieren, dass er unerlaubterweise Daten lesen kann, die nach der Datenstruktur gespeichert sind.

Um dein Programm vor dieser Art Verwundbarkeit zu schützen, wird Rust beim Versuch, ein Element an einem Index zu lesen, der nicht existiert, die Ausführung stoppen und die Fortsetzung verweigern. Versuchen wir es und sehen, was passiert:

$ cargo run
   Compiling panic v0.1.0 (file:///projects/panic)
    Finished dev [unoptimized + debuginfo] target(s) in 0.27s
     Running `target/debug/panic`
thread 'main' panicked at src/main.rs:4:6:
index out of bounds: the len is 3 but the index is 99
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Dieser Fehler weist auf Zeile 4 in unserer main.rs hin, wo wir versuchen, auf den Index 99 zuzugreifen. Die nächste Hinweiszeile sagt uns, dass wir die Umgebungsvariable RUST_BACKTRACE setzen können, um einen Backtrace zu erhalten, was genau passiert ist, das den Fehler verursacht hat. Ein Backtrace ist eine Liste aller Funktionen, die aufgerufen wurden, um an diesen Punkt zu gelangen. Backtraces in Rust funktionieren wie in anderen Sprachen: Der Schlüssel zum Lesen des Backtraces ist, von oben zu beginnen und zu lesen, bis du Dateien siehst, die du geschrieben hast. Das ist die Stelle, an der das Problem entstanden ist. Die Zeilen darüber sind Code, den dein Code aufgerufen hat; die Zeilen darunter sind Code, der deinen Code aufgerufen hat. Diese Zeilen können Core-Rust-Code, Code der Standardbibliothek oder Kisten, enthalten, die du verwendest. Versuchen wir, einen Backtrace zu erhalten, indem wir die Umgebungsvariable RUST_BACKTRACE auf einen beliebigen Wert außer 0 setzen. Codeblock 9-2 zeigt eine ähnliche Ausgabe wie die, die du sehen wirst.

$ RUST_BACKTRACE=1 cargo run
thread 'main' panicked at src/main.rs:4:6:
index out of bounds: the len is 3 but the index is 99
stack backtrace:
   0: rust_begin_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/07dca489ac2d933c78d3c5158e3f43/library/core/src/panicking.rs:72:14
   2: core::panicking::panic_bounds_check
             at /rustc/07dca489ac2d933c78d3c5158e3f43/library/core/src/panicking.rs:208:5
   3: <usize as core::slice::index::SliceIndex<[T]>>::index
             at /rustc/07dca489ac2d933c78d3c5158e3f43/library/core/src/slice/index.rs:255:10
   4: core::slice::index::<impl core::ops::index::Index<I> for [T]>::index
             at /rustc/07dca489ac2d933c78d3c5158e3f43/library/core/src/slice/index.rs:18:9
   5: <alloc::vec::Vec<T,A> as core::ops::index::Index<I>>::index
             at /rustc/07dca489ac2d933c78d3c5158e3f43/library/alloc/src/vec/mod.rs:2770:9
   6: panic::main
             at ./src/main.rs:4:6
   7: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Codeblock 9-2: Aufrufhistorie, erzeugt durch einen Aufruf von panic!, wenn die Umgebungsvariable RUST_BACKTRACE gesetzt ist

Das ist eine lange Ausgabe! Die genaue Ausgabe kann je nach Betriebssystem und Rust-Version unterschiedlich sein. Um Aufrufhistorien mit diesen Informationen zu erhalten, müssen Fehlersuchinfos (debug symbols) aktiviert sein. Fehlersuchinfos sind standardmäßig aktiviert, wenn du cargo build oder cargo run ohne Flag --release verwendest, wie wir es hier haben.

In der Ausgabe in Codeblock 9-2 zeigt Zeile 17 der Aufrufhistorie auf die Zeile in unserem Projekt, die das Problem verursacht: Zeile 4 in src/main.rs. Wenn wir nicht wollen, dass unser Programm abbricht, sollten wir bei der ersten Zeile, die auf eine von uns geschriebenen Datei verweist, mit der Untersuchung beginnen. In Codeblock 9-1, wo wir absichtlich Code geschrieben haben, der das Programm abbricht, besteht die Möglichkeit das Problem zu beheben darin, kein Element außerhalb des Bereichs der Vektorindizes anzufordern. Wenn dein Code in Zukunft abbricht, musst du herausfinden, bei welcher Aktion der Code mit welchen Werten abbricht und was der Code stattdessen tun sollte.

In Abschnitt „Wann panic! verwenden und wann nicht?“ später in diesem Kapitel kommen wir noch einmal auf panic! zurück und wann wir panic! verwenden sollten und wann nicht, um Fehlerfälle zu behandeln. Als Nächstes schauen wir uns an, wie man Fehler mit Result abfangen kann.

Behebbare Fehler mit Result

Die meisten Fehler sind nicht so schwerwiegend, dass das Programm ganz abgebrochen werden müsste. Manchmal, wenn eine Funktion fehlschlägt, hat das einen Grund, den man leicht erkennen und darauf reagieren kann. Wenn du beispielsweise versuchst, eine Datei zu öffnen, und dieser Vorgang schlägt fehl, weil die Datei nicht existiert, könntest du die Datei erstellen, anstatt den Vorgang zu beenden.

Erinnere dich an „Behandeln potentieller Fehler mit dem Typ Result“ in Kapitel 2, das die Aufzählung Result mit zwei Varianten Ok und Err definiert, wie nachfolgend zu sehen ist:

#![allow(unused)]
fn main() {
enum Result<T, E> {
    Ok(T),
    Err(E),
}
}

T und E sind generische Typparameter: Wir werden generische Datentypen in Kapitel 10 ausführlicher besprechen. Was du jetzt wissen musst, ist, dass T den Typ des Wertes darstellt, der im Erfolgsfall innerhalb der Ok-Variante zurückgegeben wird, und E den Typ des Fehlers, der im Fehlerfall innerhalb der Err-Variante zurückgegeben wird. Da Result diese generischen Typparameter hat, können wir den Result-Typ und die Funktionen, die darauf definiert sind, in vielen verschiedenen Situationen verwenden, in denen der Erfolgswert und der Fehlerwert, den wir zurückgeben wollen, unterschiedlich sein können.

Rufen wir eine Funktion auf, die einen Result-Wert zurückgibt, weil die Funktion fehlschlagen könnte. In Codeblock 9-3 versuchen wir, eine Datei zu öffnen.

Dateiname: src/main.rs

use std::fs::File;

fn main() {
    let greeting_file_result = File::open("hallo.txt");
}

Codeblock 9-3: Eine Datei öffnen

Der Rückgabetyp von File::open ist Result<T, E>. Der generische Parameter T wurde hier mit dem Typ des Erfolgswertes std::fs::File, der eine Dateiressource (file handle) ist, gefüllt. Der Typ E für den Fehlerwert ist std::io::Error. Dieser Rückgabetyp bedeutet, dass der Aufruf von File::open erfolgreich sein könnte und eine Dateiressource zurückgibt, aus der wir lesen oder in die wir schreiben können. Der Funktionsaufruf kann auch fehlschlagen: Zum Beispiel könnte die Datei nicht existieren oder wir haben möglicherweise keine Zugriffsberechtigung für die Datei. Die Funktion File::open muss eine Möglichkeit haben, uns zu sagen, ob sie erfolgreich war oder fehlgeschlagen ist, und uns gleichzeitig entweder die Dateiressource oder die Fehlerinformationen liefern. Diese Informationen sind genau das, was die Aufzählung Result übermittelt.

Falls File::open erfolgreich ist, wird der Wert der Variable greeting_file_result eine Instanz von Ok sein, die eine Dateiressource enthält. Im Fehlerfall ist der Wert von greeting_file_result eine Instanz von Err, die mehr Informationen über die Art des aufgetretenen Fehlers enthält.

Wir müssen den Code in Codeblock 9-3 ergänzen, um abhängig vom Rückgabewert von File::open unterschiedliche Aktionen durchzuführen. Codeblock 9-4 zeigt eine Möglichkeit, Result mit Hilfe eines grundlegenden Werkzeugs, dem Ausdruck match, den wir in Kapitel 6 besprochen haben, zu behandeln.

Dateiname: src/main.rs

use std::fs::File;

fn main() {
    let greeting_file_result = File::open("hallo.txt");

    let greeting_file = match greeting_file_result {
        Ok(file) => file,
        Err(error) => panic!("Problem beim Öffnen der Datei: {:?}", error),
    };
}

Codeblock 9-4: Verwenden eines match-Ausdrucks zum Behandeln der Result-Varianten, die zurückgegeben werden könnten

Beachte, dass die Aufzählung Result und ihre Varianten automatisch im Gültigkeitsbereich verfügbar sind, genau wie bei der Aufzählung Option, sodass wir in den match-Zweigen nicht mehr Result:: vor den Varianten Ok und Err angeben müssen.

Wenn das Ergebnis Ok ist, gibt dieser Code den inneren file-Wert aus der Ok-Variante zurück, und wir weisen diese Dateiressource der Variablen greeting_file zu. Nach dem match können wir die Dateiressource zum Lesen und Schreiben verwenden.

Der andere Zweig von match behandelt den Fall, dass wir einen Err-Wert von File::open erhalten. In diesem Beispiel haben wir uns dafür entschieden, das Makro panic! aufzurufen. Wenn es keine Datei namens hallo.txt in unserem aktuellen Verzeichnis gibt und wir diesen Code ausführen, sehen wir die folgende Ausgabe des Makros panic!:

$ cargo run
   Compiling error-handling v0.1.0 (file:///projects/error-handling)
    Finished dev [unoptimized + debuginfo] target(s) in 0.73s
     Running `target/debug/error-handling`
thread 'main' panicked at src/main.rs:8:23:
Problem beim Öffnen der Datei: Os { code: 2, kind: NotFound, message: "No such file or directory" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Wie üblich sagt uns diese Ausgabe genau, was schiefgelaufen ist.

Abgleich verschiedener Fehler

Der Code in Codeblock 9-4 wird abbrechen, egal aus welchem Grund File::open fehlschlug. Nun wollen wir jedoch bei verschiedenen Fehlerursachen unterschiedliche Maßnahmen ergreifen: Wenn File::open fehlgeschlagen ist, weil die Datei nicht existiert, wollen wir die Datei erstellen und die Dateiressource der neuen Datei zurückgeben. Wenn File::open aus irgendeinem anderen Grund fehlschlug, z.B. weil wir keine Berechtigung zum Öffnen der Datei hatten, wollen wir immer noch, dass der Code abbricht, so wie es in Codeblock 9-4 der Fall war. Dazu fügen wir einen inneren match-Ausdruck hinzu, wie in Codeblock 9-5 gezeigt.

Dateiname: src/main.rs

use std::fs::File;
use std::io::ErrorKind;

fn main() {
    let greeting_file_result = File::open("hallo.txt");

    let greeting_file = match greeting_file_result {
        Ok(file) => file,
        Err(error) => match error.kind() {
            ErrorKind::NotFound => match File::create("hallo.txt") {
                Ok(fc) => fc,
                Err(e) => panic!("Problem beim Erstellen der Datei: {:?}", e),
            },
            other_error => {
                panic!("Problem beim Öffnen der Datei: {:?}", other_error)
            }
        },
    };
}

Codeblock 9-5: Unterschiedliche Arten von Fehlern auf unterschiedliche Weise behandeln

Der Typ des Wertes, den File::open innerhalb der Variante Err zurückgibt, ist io::Error, eine Struktur (struct), die von der Standardbibliothek zur Verfügung gestellt wird. Diese Struktur hat eine Methode kind, die wir aufrufen können, um einen io::ErrorKind-Wert zu erhalten. Die Aufzählung io::ErrorKind wird von der Standardbibliothek zur Verfügung gestellt und enthält Varianten, die die verschiedenen Fehlerarten repräsentieren, die bei einer io-Operation auftreten können. Die Variante, die wir verwenden wollen, ist ErrorKind::NotFound, was bedeutet, dass die Datei, die wir zu öffnen versuchen, noch nicht existiert. Wir werten also greeting_file_result aus, als auch error.kind().

Die Bedingung, die wir beim inneren Abgleich überprüfen wollen, ist, ob der von error.kind() zurückgegebene Wert die Variante NotFound der Aufzählung ErrorKind ist. Wenn das der Fall ist, versuchen wir, die Datei mit File::create zu erstellen. Da File::create aber auch scheitern könnte, brauchen wir einen zweiten Zweig im inneren match-Ausdruck. Wenn die Datei nicht erstellt werden kann, wird eine andere Fehlermeldung ausgegeben. Der zweite Zweig des äußeren match bleibt gleich, sodass das Programm bei jedem Fehler, außer dem Fehler der fehlenden Datei, abbricht.

Alternativen zur Verwendung von match mit Result<T, E>

Das sind viele match! Der Ausdruck match ist sehr nützlich, aber auch sehr primitiv. In Kapitel 13 wirst du etwas über Funktionsabschlüsse (closures) lernen, die mit vielen der auf Result<T, E> definierten Methoden verwendet werden. Diese Methoden können prägnanter sein als die Verwendung von match bei der Behandlung von Result<T, E>-Werten in deinem Code.

Hier ist zum Beispiel eine andere Möglichkeit, die gleiche Logik wie in Codeblock 9-5 zu schreiben, aber unter Verwendung von Funktionsabschlüssen und der Methode unwrap_or_else:

use std::fs::File;
use std::io::ErrorKind;

fn main() {
    let greeting_file = File::open("hallo.txt").unwrap_or_else(|error| {
        if error.kind() == ErrorKind::NotFound {
            File::create("hallo.txt").unwrap_or_else(|error| {
                panic!("Problem beim Erstellen der Datei: {:?}", error);
            })
        } else {
            panic!("Problem beim Öffnen der Datei: {:?}", error);
        }
    });
}

Obwohl dieser Code dasselbe Verhalten wie Codeblock 9-5 aufweist, enthält er keine match-Ausdrücke und ist einfacher zu lesen. Kehre zu diesem Beispiel zurück, nachdem du Kapitel 13 gelesen hast, und schlage die Methode unwrap_or_else in der Standardbibliotheksdokumentation nach. Viele weitere dieser Methoden können große, verschachtelte match-Ausdrücke vermeiden, wenn du mit Fehlern zu tun hast.

Abkürzungen zum Abbrechen im Fehlerfall: unwrap und expect

Das Verwenden von match funktioniert gut genug, aber es kann etwas langatmig sein und vermittelt das Vorhaben nicht immer gut. Der Typ Result<T, E> bietet viele Hilfsmethoden, um verschiedene, spezifischere Aufgaben zu erledigen. Die Methode unwrap ist eine Abkürzungsmethode, implementiert wie der Ausdruck match, den wir in Codeblock 9-4 verwendet haben. Wenn der Result-Wert die Variante Ok ist, gibt unwrap den Wert innerhalb Ok zurück. Wenn Result die Variante Err ist, ruft unwrap das Makro panic! für uns auf. Hier ist ein Beispiel für unwrap im Einsatz:

Dateiname: src/main.rs

use std::fs::File;

fn main() {
    let greeting_file = File::open("hallo.txt").unwrap();
}

Wenn wir diesen Code ohne eine Datei hallo.txt ausführen, werden wir die Fehlermeldung des panic!-Aufrufs sehen, den die Methode unwrap macht:

thread 'main' panicked at src/main.rs:4:49:
called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }

In ähnlicher Weise können wir bei der Methode expect auch die Fehlermeldung von panic! angeben. Das Verwenden von expect anstelle von unwrap und das Angeben guter Fehlermeldungen kann deine Absicht vermitteln und das Aufspüren der Fehlerursache erleichtern. Die Syntax von expect sieht wie folgt aus:

Dateiname: src/main.rs

use std::fs::File;

fn main() {
    let greeting_file = File::open("hallo.txt")
        .expect("hallo.txt sollte in dieses Projekt aufgenommen werden");
}

Wir benutzen expect auf die gleiche Weise wie unwrap: Um die Dateiressource zurückzugeben oder das Makro panic! aufzurufen. Die Fehlermeldung, die expect beim Aufruf von panic! mitgibt, wird als Parameter an expect übergeben, anstelle der standardmäßigen panic!-Nachricht, die unwrap verwendet. So sieht sie aus:

thread 'main' panicked at src/main.rs:5:10:
hallo.txt sollte in dieses Projekt aufgenommen werden: Os { code: 2, kind: NotFound, message: "No such file or directory" }

In produktivem Code wählen die meisten Rust-Entwickler expect statt unwrap und geben mehr Kontext darüber an, warum die Operation voraussichtlich immer erfolgreich sein wird. Auf diese Weise hast du mehr Informationen, die du bei der Fehlersuche verwenden kannst, falls sich deine Annahmen als falsch erweisen sollten.

Weitergabe von Fehlern

Wenn die Implementierung einer Funktion etwas aufruft, das fehlschlagen könnte, kannst du, anstatt den Fehler innerhalb dieser Funktion zu behandeln, den Fehler an den aufrufenden Code zurückgeben, damit dieser entscheiden kann, was zu tun ist. Dies wird als Weitergeben (propagating) des Fehlers bezeichnet und gibt dem aufrufenden Code mehr Kontrolle, wo mehr Informationen und Logik zur Fehlerbehandlung vorhanden sein könnte, als im Kontext deines Codes zur Verfügung steht.

Beispielsweise zeigt Codeblock 9-6 eine Funktion, die einen Benutzernamen aus einer Datei liest. Wenn die Datei nicht existiert oder nicht gelesen werden kann, gibt diese Funktion den Fehler an den Code zurück, der die Funktion aufgerufen hat.

Dateiname: src/main.rs

#![allow(unused)]
fn main() {
use std::fs::File;
use std::io::{self, Read};

fn read_username_from_file() -> Result<String, io::Error> {
    let username_file_result = File::open("hallo.txt");

    let mut username_file = match username_file_result  {
        Ok(file) => file,
        Err(e) => return Err(e),
    };

    let mut username = String::new();

    match username_file.read_to_string(&mut username) {
        Ok(_) => Ok(username),
        Err(e) => Err(e),
    }
}
}

Codeblock 9-6: Eine Funktion, die mit match Fehler an den aufrufenden Code zurückgibt

Diese Funktion kann auf eine viel kürzere Art und Weise geschrieben werden, aber wir wollen für den Anfang viel davon manuell machen, um die Fehlerbehandlung kennen zu lernen; am Ende werden wir den kürzeren Weg zeigen. Sehen wir uns zunächst den Rückgabetyp der Funktion an: Result<String, io::Error>. Das bedeutet, dass die Funktion einen Wert vom Typ Result<T, E> zurückgibt, wobei der generische Typ T mit dem konkreten Typ String und der generische Typ E mit dem konkreten Typ io::Error gefüllt wurde.

Wenn diese Funktion erfolgreich ist, erhält der aufrufende Code einen Ok-Wert, der einen String enthält – den Benutzernamen, den diese Funktion aus der Datei liest. Wenn diese Funktion auf Probleme stößt, erhält der aufrufende Code einen Err-Wert, der eine Instanz von io::Error enthält, mit weiteren Informationen darüber, was die Probleme waren. Wir wählten io::Error als Rückgabetyp dieser Funktion, weil dies zufällig der Typ des Fehlerwertes ist, der von beiden Operationen zurückgegeben wird, die wir im Funktionsrumpf aufrufen und fehlschlagen könnten: Die Funktion File::open und die Methode read_to_string.

Der Funktionsrumpf beginnt mit dem Aufruf der Funktion File::open. Dann behandeln wir den Result-Wert, der von match zurückgegeben wird, auf ähnliche Weise wie bei match in Codeblock 9-4. Wenn File::open erfolgreich ist, erhält die Dateiressource in der Mustervariablen file den Wert in der veränderbaren Variablen username_file und die Funktion wird fortgesetzt. Im Fall von Err verwenden wir das Schlüsselwort return, anstatt panic! aufzurufen, um die Funktion vorzeitig ganz zu verlassen und den Fehlerwert von File::open in der Mustervariablen e als Fehlerwert dieser Funktion an den aufrufenden Code zurückzugeben.

Wenn wir also eine Dateiressource in username_file haben, erzeugt die Funktion einen neuen String in der Variablen username und ruft die Methode read_to_string für die Dateiressource in username_file auf, um den Inhalt der Datei in die Variable username zu lesen. Die Methode read_to_string gibt ebenfalls ein Result zurück, weil sie fehlschlagen könnte, obwohl File::open erfolgreich war. Wir brauchen also ein weiteres match, um dieses Result zu verarbeiten: Wenn read_to_string erfolgreich ist, dann war unsere Funktion erfolgreich und wir geben den Benutzernamen aus der Datei zurück, die jetzt in username innerhalb Ok enthalten ist. Wenn read_to_string fehlschlägt, geben wir den Fehlerwert auf die gleiche Weise zurück, wie wir den Fehlerwert in match zurückgegeben haben, das den Rückgabewert von File::open behandelt hat. Wir brauchen jedoch nicht ausdrücklich return anzugeben, weil dies der letzte Ausdruck in der Funktion ist.

Der Code, der diesen Code aufruft, wird dann damit zurechtkommen, entweder einen Ok-Wert zu erhalten, der einen Benutzernamen enthält, oder einen Err-Wert, der einen io::Error enthält. Es ist Sache des aufrufenden Codes, zu entscheiden, was mit diesen Werten geschehen soll. Wenn der aufrufende Code einen Err-Wert erhält, könnte er panic! aufrufen und das Programm zum Absturz bringen, einen Standardbenutzernamen verwenden oder den Benutzernamen von irgendwo anders als z.B. einer Datei nachschlagen. Wir haben nicht genug Informationen darüber, was der aufrufende Code tatsächlich versucht, also propagieren wir alle Erfolgs- und Fehlerinformationen nach oben, damit sie angemessen behandelt werden.

Dieses Muster der Fehlerweitergabe ist in Rust so verbreitet, dass Rust den Fragezeichen-Operator ? bereitstellt, um dies zu erleichtern.

Abkürzung zum Weitergeben von Fehlern: Der Operator ?

Codeblock 9-7 zeigt eine Implementierung von read_username_from_file, die dasselbe Verhalten wie Codeblock 9-6 hat, aber diese Implementierung verwendet den ?-Operator.

Dateiname: src/main.rs

#![allow(unused)]
fn main() {
use std::fs::File;
use std::io;
use std::io::Read;

fn read_username_from_file() -> Result<String, io::Error> {
    let mut username_file = File::open("hallo.txt")?;
    let mut username = String::new();
    username_file.read_to_string(&mut username )?;
    Ok(username)
}
}

Codeblock 9-7: Eine Funktion, die Fehler an den aufrufenden Code zurückgibt, indem sie den ?-Operator verwendet

Das ? hinter dem Result-Wert bewirkt fast das gleiche wie die match-Ausdrücke, die wir zum Behandeln der Result-Werte in Codeblock 9-6 definiert haben. Wenn der Wert von Result ein Ok ist, wird der Wert innerhalb Ok zurückgegeben und das Programm fortgesetzt. Wenn der Wert ein Err ist, wird er als Funktionsergebnis zurückgegeben, als ob wir das Schlüsselwort return verwendet hätten.

Es gibt einen Unterschied zwischen dem, was der match-Ausdruck aus Codeblock 9-6 tut, und dem, was der ?-Operator tut: Fehlerwerte, bei denen der ?-Operator aufgerufen wird, durchlaufen die Funktion from, die im Merkmal From der Standardbibliothek definiert ist und die zur Konvertierung von Werten eines Typs in einen anderen verwendet wird. Wenn der ?-Operator die Funktion from aufruft, wird der empfangene Fehlertyp in den Fehlertyp umgewandelt, der als Rückgabetyp der aktuellen Funktion definiert ist. Das ist hilfreich, wenn eine Funktion einen einzigen Fehlertyp zurückgibt, um alle möglichen Fehlerarten einer Funktion darzustellen, auch wenn Teile aus vielen verschiedenen Gründen versagen könnten.

Wir könnten zum Beispiel die Funktion read_username_from_file in Codeblock 9-7 so ändern, dass sie einen von uns definierten Fehlertyp namens OurError zurückgibt. Wenn wir auch impl From<io::Error> for OurError definieren, um eine Instanz von OurError aus einem io::Error zu konstruieren, dann werden die ?-Operator-Aufrufe im Rumpf von read_username_from_file from aufrufen und die Fehlertypen konvertieren, ohne dass weiterer Code zur Funktion hinzugefügt werden muss.

Im Zusammenhang mit Codeblock 9-7 gibt das ? am Ende des Aufrufs von File::open den Wert innerhalb eines Ok an die Variable username_file zurück. Wenn ein Fehler auftritt, beendet der Operator vorzeitig die gesamte Funktion und gibt dem aufrufenden Code einen Err-Wert zurück. Dasselbe gilt für das ? am Ende des read_to_string-Aufrufs.

Der ?-Operator eliminiert viel umständlichen Code und macht die Implementierung dieser Funktion einfacher. Wir können diesen Code sogar noch weiter verkürzen, indem wir die Methodenaufrufe unmittelbar nach dem ? verketten, wie in Codeblock 9-8 zu sehen ist.

Dateiname: src/main.rs

#![allow(unused)]
fn main() {
use std::fs::File;
use std::io;
use std::io::Read;

fn read_username_from_file() -> Result<String, io::Error> {
    let mut username = String::new();

    File::open("hallo.txt")?.read_to_string(&mut username)?;

    Ok(username)
}
}

Codeblock 9-8: Verketten von Methodenaufrufen nach dem ?-Operator

Wir haben das Erstellen des neuen String in username an den Anfang der Funktion verlegt; dieser Teil hat sich nicht geändert. Anstatt eine Variable username_file zu erzeugen, haben wir den Aufruf von read_to_string direkt an das Ergebnis von File::open("hallo.txt")? gehängt. Wir haben immer noch ein ? am Ende des Aufrufs von read_to_string, und wir geben immer noch einen Ok-Wert zurück, der username enthält, wenn sowohl File::open als auch read_to_string erfolgreich sind, anstatt Fehler zurückzugeben. Die Funktionalität ist wieder die gleiche wie in Codeblock 9-6 und Codeblock 9-7; das ist nur eine andere, ergonomischere Schreibweise.

Codeblock 9-9 zeigt, dass es einen Weg gibt, diese Funktion noch kürzer zu machen.

Dateiname: src/main.rs

#![allow(unused)]
fn main() {
use std::fs;
use std::io;

fn read_username_from_file() -> Result<String, io::Error> {
    fs::read_to_string("hallo.txt")
}
}

Codeblock 9-9: Verwenden von fs::read_to_string, anstatt die Datei zu öffnen und dann zu lesen

Das Einlesen einer Datei in eine Zeichenkette ist eine ziemlich häufig benötigte Operation, daher bringt die Standardbibliothek die praktische Funktion fs::read_to_string mit, die die Datei öffnet, einen neuen String erzeugt, den Inhalt der Datei einliest, den Inhalt in den String einfügt und ihn zurückgibt. Natürlich gibt uns die Verwendung von fs::read_to_string nicht die Möglichkeit, die ganze Fehlerbehandlung zu erklären, also haben wir es zuerst auf dem längeren Weg gemacht.

Wo der Operator ? verwendet werden kann

Der Operator ? kann nur in Funktionen verwendet werden, deren Rückgabetyp mit dem Wert, auf den ? angewendet wird, kompatibel ist. Das liegt daran, dass der Operator ? so definiert ist, dass er einen Wert frühzeitig aus der Funktion zurückgibt, genauso wie der Ausdruck match, den wir in Codeblock 9-6 definiert haben. In Codeblock 9-6 verwendet match einen Result-Wert, und der frühe Rückgabezweig liefert einen Err(e)-Wert. Der Rückgabetyp der Funktion muss ein Result sein, damit er mit return kompatibel ist.

Schauen wir uns in Codeblock 9-10 an, was passiert, wenn wir den ?-Operator in einer main-Funktion verwenden, deren Rückgabetyp nicht mit dem Typ des Wertes, für den wir "?" verwenden, kompatibel ist:

Dateiname: src/main.rs

use std::fs::File;

fn main() {
    let greeting_file = File::open("hallo.txt")?;
}

Codeblock 9-10: Der Versuch, das ? in der main-Funktion zu verwenden, die () zurückgibt, lässt sich nicht kompilieren

Dieser Code öffnet eine Datei, was fehlschlagen kann. Der ?-Operator folgt dem Result-Wert, der von File::open zurückgegeben wird, aber diese main-Funktion hat den Rückgabetyp (), nicht Result. Wenn wir diesen Code kompilieren, erhalten wir folgende Fehlermeldung:

$ cargo run
   Compiling error-handling v0.1.0 (file:///projects/error-handling)
error[E0277]: the `?` operator can only be used in a function that returns `Result` or `Option` (or another type that implements `FromResidual`)
 --> src/main.rs:4:48
  |
3 | fn main() {
  | --------- this function should return `Result` or `Option` to accept `?`
4 |     let greeting_file = File::open("hallo.txt")?;
  |                                                ^ cannot use the `?` operator in a function that returns `()`
  |
  = help: the trait `FromResidual<Result<Infallible, std::io::Error>>` is not implemented for `()`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `error-handling` (bin "error-handling") due to 1 previous error

Dieser Fehler weist darauf hin, dass wir den ?-Operator nur in einer Funktion verwenden dürfen, die Result oder Option oder einen anderen Typ, der FromResidual implementiert, zurückgibt.

Um den Fehler zu beheben, hast du zwei Möglichkeiten. Eine Möglichkeit besteht darin, den Rückgabetyp deiner Funktion so zu ändern, dass er mit dem Wert kompatibel ist, für den du den Operator ? verwendest, wenn dem nichts entgegensteht. Die andere Möglichkeit besteht darin, match oder eine der Methoden von Result<T, E> zu verwenden, um Result<T, E> in geeigneter Weise zu behandeln.

Die Fehlermeldung hat auch erwähnt, dass ? ebenso mit Option<T>-Werten verwendet werden kann. Wie bei der Verwendung von ? für Result, kannst du ? für Option nur in einer Funktion verwenden, die eine Option zurückgibt. Das Verhalten des ?-Operators beim Aufruf auf eine Option<T> ist ähnlich dem Verhalten, wenn er auf ein Result<T, E> aufgerufen wird: Wenn der Wert None ist, wird None zu diesem Zeitpunkt von der Funktion zurückgegeben. Wenn der Wert Some ist, ist der Wert innerhalb von Some der resultierende Wert des Ausdrucks und die Funktion wird fortgesetzt. Codeblock 9-11 zeigt ein Beispiel für eine Funktion, die das letzte Zeichen der ersten Zeile in einem gegebenen Text findet:

fn last_char_of_first_line(text: &str) -> Option<char> {
    text.lines().next()?.chars().last()
}

fn main() {
    assert_eq!(
        last_char_of_first_line("Hallo Welt\nWie geht es dir heute?"),
        Some('t')
    );

    assert_eq!(last_char_of_first_line(""), None);
    assert_eq!(last_char_of_first_line("\nhi"), None);
}

Codeblock 9-11: Verwenden des ?-Operators auf einem Option<T>-Wert

Diese Funktion gibt Option<char> zurück, weil es möglich ist, dass ein Zeichen vorhanden ist, aber es ist auch möglich, dass keines vorhanden ist. Dieser Code nimmt das Zeichenkettenanteilstyp-Argument text und ruft die Methode lines darauf auf, die einen Iterator über die Zeilen der Zeichenkette zurückgibt. Da diese Funktion die erste Zeile untersuchen will, ruft sie next auf dem Iterator auf, um den ersten Wert vom Iterator zu erhalten. Wenn text die leere Zeichenkette ist, gibt dieser Aufruf von next None zurück, und hier können wir ? benutzen, um zu stoppen und None von last_char_of_first_line zurückgeben, wenn dies der Fall ist. Wenn text nicht die leere Zeichenkette ist, gibt next einen Some-Wert zurück, der einen Zeichenkettenanteilstyp der ersten Zeile in text enthält.

Das ? extrahiert den Zeichenkettenanteilstyp, und wir können chars auf diesem Zeichenkettenanteilstyp aufrufen, um einen Iterator für seine Zeichen zu erhalten. Wir sind am letzten Zeichen in dieser ersten Zeile interessiert, also rufen wir last auf, um das letzte Element im Iterator über die Zeichen zurückzugeben. Dies ist eine Option, weil die erste Zeile die leere Zeichenkette sein kann, wenn text mit einer Leerzeile beginnt, aber Zeichen in anderen Zeilen enthält, wie in "\nhi". Wenn es jedoch ein letztes Zeichen in der ersten Zeile gibt, wird es in der Variante Some zurückgegeben. Der ?-Operator in der Mitte gibt uns eine prägnante Möglichkeit, diese Logik auszudrücken, und diese Funktion kann in einer Zeile implementiert werden. Wenn wir den ?-Operator nicht auf Option verwenden könnten, müssten wir diese Logik mit weiteren Methodenaufrufen oder einem Ausdruck implementieren.

Beachte, dass du den ?-Operator auf ein Result in einer Funktion anwenden kannst, die Result zurückgibt, und du kannst den ?-Operator auf eine Option in einer Funktion anwenden, die Option zurückgibt, aber du kannst nicht beides mischen. Der Operator ? konvertiert nicht automatisch ein Result in eine Option oder umgekehrt; in diesen Fällen kannst du Methoden wie ok für Result oder ok_or für Option verwenden, die die Umwandlung explizit vornehmen.

Bis jetzt haben alle main-Funktionen, die wir benutzt haben, () zurückgegeben. Die Funktion main ist etwas Besonderes, weil sie der Ein- und Ausstiegspunkt von ausführbaren Programmen ist, und es gibt Einschränkungen hinsichtlich ihres Rückgabetyps, damit sich die Programme wie erwartet verhalten.

Glücklicherweise kann main auch ein Result<(), E> zurückgeben. Codeblock 9-12 enthält den Code aus Codeblock 9-10, aber wir haben den Rückgabetyp von main in Result<(), Box<dyn Error>> geändert und am Ende einen Rückgabewert Ok(()) hinzugefügt. Dieser Code wird nun kompilieren:

use std::error::Error;
use std::fs::File;

fn main() -> Result<(), Box<dyn Error>> {
    let greeting_file = File::open("hallo.txt")?;

    Ok(())
}

Codeblock 9-12: Die Änderung von main zur Rückgabe von Result<(), E> erlaubt die Verwendung des ?-Operators für Result-Werte

Der Typ Box<dyn Error> ist ein Merkmalsobjekt (trait object), über das wir im Abschnitt „Merkmalsobjekte (trait objects) die Werte unterschiedlicher Typen erlauben“ in Kapitel 17 sprechen werden. Vorerst kannst du Box<dyn Error> als „eine beliebige Fehlerart“ ansehen. Das Verwenden von ? auf einen Result-Wert in einer main-Funktion mit dem Fehlertyp Box<dyn Error> ist erlaubt, weil dadurch ein Err-Wert frühzeitig zurückgegeben werden kann. Obwohl der Rumpf dieser main-Funktion nur Fehler des Typs std::io::Error zurückgibt, ist diese Signatur durch die Angabe von Box<dyn Error> auch dann noch korrekt, wenn weiterer Code, der andere Fehler zurückgibt, dem Rumpf von main hinzugefügt wird.

Wenn eine main-Funktion ein Result<(), E> zurückgibt, beendet sich die ausführbare Datei mit einem Wert von 0, wenn main den Wert Ok(()) zurückgibt, und mit einem Wert ungleich Null, wenn main einen Err-Wert zurückgibt. In C geschriebene ausführbare Programme geben beim Beenden ganze Zahlen zurück: Programme, die erfolgreich beendet werden, geben die Zahl 0 zurück, und Programme, die einen Fehler machen, geben eine Zahl ungleich 0 zurück. Rust gibt ebenfalls ganze Zahlen aus ausführbaren Dateien zurück, um mit dieser Konvention kompatibel zu sein.

Die Funktion main kann jeden Typ zurückgeben, der das Merkmal std::process::Termination implementiert, das eine Funktion report enthält, die einen ExitCode zurückgibt. Weitere Informationen zur Implementierung des Merkmals Termination für deine eigenen Typen findest du in der Dokumentation der Standardbibliothek.

Nachdem wir nun die Einzelheiten des Aufrufs von panic! und der Rückgabe von Result besprochen haben, wollen wir zum Thema zurückkehren, wie wir entscheiden können, was in welchen Fällen geeignet ist.

Wann panic! aufrufen und wann nicht?

Wie entscheidest du also, wann du panic! aufrufen und wann Result zurückgeben sollst? Wenn Code abbricht, gibt es keine Möglichkeit sich vom Fehler zu erholen. Du könntest panic! in jeder Fehlersituation aufrufen, unabhängig davon, ob es eine Möglichkeit zur Fehlerbehebung gibt oder nicht, aber dann triffst du die Entscheidung für den aufrufenden Code, dass eine Situation nicht rettbar ist. Wenn du dich dafür entscheidest, einen Result-Wert zurückzugeben, überlässt du dem aufrufenden Code die Wahlmöglichkeit, anstatt die Entscheidung für ihn zu treffen. Der aufrufende Code könnte sich dafür entscheiden, sich vom Fehler auf eine sinnvolle Weise zu erholen, oder er könnte sich dafür entscheiden, dass ein Err-Wert in diesem Fall nicht behebbar ist und panic! aufrufen, und so deinen behebbaren Fehler in einen nicht behebbaren verwandeln. Daher ist die Rückgabe von Result eine gute Standardwahl, wenn du eine Funktion definierst, die fehlschlagen könnte.

In Beispielen, Prototyp-Code und Tests ist es sinnvoller, Code zu schreiben, der das Programm abbricht, anstatt ein Result zurückzugeben. Lass uns herausfinden, warum das so ist, und dann Situationen besprechen, in denen der Compiler nicht feststellen kann, dass ein Fehler unmöglich ist, du als Mensch aber schon. Das Kapitel schließt mit einigen allgemeinen Richtlinien zur Entscheidung, ob in Bibliothekscode ein Programm abgebrochen werden soll.

Beispiele, Code-Prototypen und Tests

Wenn du ein Beispiel schreibst, um ein Konzept zu veranschaulichen, kann die Einbeziehung von robustem Fehlerbehandlungscode das Beispiel unklarer machen. In Beispielen wird davon ausgegangen, dass der Aufruf einer Methode wie unwrap, die das Programm abbrechen könnte, als Platzhalter für die Art und Weise gedacht ist, wie deine Anwendung mit Fehlern umgehen soll, die je nachdem, was der Rest deines Codes tut, unterschiedlich sein können.

In ähnlicher Weise sind die Methoden unwrap und expect bei Prototypen sehr praktisch, wenn du noch nicht entscheiden willst, wie mit Fehlern umzugehen ist. Du hinterlässt klare Markierungen in deinem Code für später, wenn du dein Programm robuster machst.

Wenn ein Methodenaufruf in einem Test fehlschlägt, würdest du wollen, dass der gesamte Test fehlschlägt, auch wenn diese Methode nicht die zu testende Funktionalität ist. Da ein Test mit panic! als fehlgeschlagen markiert wird, ist der Aufruf von unwrap und expect genau das, was passieren sollte.

Fälle, in denen du mehr Informationen als der Compiler hast

Es wäre auch sinnvoll, unwrap oder expect aufzurufen, wenn du eine andere Logik hast, die sicherstellt, dass Result einen Ok-Wert hat, aber die Logik kann vom Compiler nicht verstanden werden. Du wirst immer noch ein Result haben, mit dem du umgehen musst: Welche Operation auch immer du aufrufst, es besteht immer noch die Möglichkeit, dass sie im Allgemeinen scheitert, auch wenn es in deiner speziellen Situation logischerweise unmöglich ist. Wenn du durch manuelle Codeinspektion sicherstellen kannst, dass du niemals eine Err-Variante haben wirst, ist es vollkommen akzeptabel, unwrap aufzurufen, und noch besser ist es, den Grund, warum du glaubst, dass du niemals eine Err-Variante haben wirst, im expect-Text zu dokumentieren. Hier ist ein Beispiel:

#![allow(unused)]
fn main() {
use std::net::IpAddr;

let home: IpAddr = "127.0.0.1"
    .parse()
    .expect("Fest programmierte IP-Adresse sollte gültig sein");
}

Wir erstellen eine IpAddr-Instanz, indem wir eine hartkodierte Zeichenkette parsen. Wir können sehen, dass 127.0.0.1 eine gültige IP-Adresse ist, sodass es akzeptabel ist, hier expect zu verwenden. Eine hartkodierte, gültige Zeichenkette ändert jedoch nicht den Rückgabetyp der parse-Methode: Wir erhalten immer noch einen Result-Wert und der Compiler wird von uns verlangen, Result so zu behandeln, als ob die Err-Variante möglich wäre, weil der Compiler nicht klug genug ist, um zu erkennen, dass diese Zeichenkette stets eine gültige IP-Adresse ist. Wenn die IP-Adressen-Zeichenkette von einem Benutzer kam, anstatt fest im Programm kodiert zu sein, und daher möglicherweise fehlschlagen könnte, würden wir stattdessen definitiv Result auf eine robustere Weise behandeln wollen.

Richtlinien zur Fehlerbehandlung

Es ist ratsam, dass dein Code abbricht, wenn es möglich ist, dass dein Code in einem schlechten Zustand enden könnte. In diesem Zusammenhang ist ein schlechter Zustand (bad state) dann gegeben, wenn eine Annahme, eine Garantie, ein Vertrag oder eine Invariante gebrochen wurde, z.B. wenn ungültige Werte, widersprüchliche Werte oder fehlende Werte an deinen Code übergeben werden – sowie einer oder mehrere der folgenden Punkte zutreffen:

• Der schlechte Zustand ist etwas Unerwartetes, im Gegensatz zu etwas, das wahrscheinlich gelegentlich vorkommt, wie die Eingabe von Daten in einem falschen Format durch einen Benutzer.
• Dein Code muss sich nach diesem Punkt darauf verlassen können, dass er sich in keinem schlechten Zustand befindet, anstatt bei jedem Schritt auf das Problem zu prüfen.
• Es gibt keine gute Möglichkeit, diese Informationen in den von dir verwendeten Typen zu kodieren. Wir werden im Abschnitt „Kodieren von Zuständen und Verhalten als Typen“ in Kapitel 17 ein Beispiel dafür durcharbeiten.

Wenn jemand deinen Code aufruft und Werte übergibt, die keinen Sinn ergeben, ist es am besten, einen Fehler zurückzugeben, damit der Benutzer der Bibliothek entscheiden kann, was er in diesem Fall tun möchte. In Fällen, in denen eine Fortsetzung unsicher oder schädlich sein könnte, ist es jedoch am besten, panic! aufzurufen und die Person, die deine Bibliothek verwendet, auf den Fehler in ihrem Code hinzuweisen, damit sie ihn während der Entwicklung beheben kann. In ähnlicher Weise ist panic! oft angebracht, wenn du externen Code aufrufst, der sich deiner Kontrolle entzieht und einen ungültigen Zustand zurückgibt, den du nicht beheben kannst.

Wenn jedoch ein Fehler erwartet wird, ist es sinnvoller, ein Result zurückzugeben, als panic! aufzurufen. Beispiele hierfür sind ein Parser, dem fehlerhafte Daten übergeben werden, oder eine HTTP-Anfrage, die einen Status zurückgibt, der anzeigt, dass du ein Aufruflimit erreicht hast. In diesen Fällen zeigt der Rückgabetyp Result an, dass ein Fehler eine erwartete Möglichkeit ist, bei der der aufrufende Code entscheiden muss, wie er damit umgeht.

Wenn dein Code einen Vorgang ausführt, der einen Benutzer gefährden könnte, wenn er mit ungültigen Werten aufgerufen wird, sollte dein Code zuerst überprüfen, ob die Werte gültig sind, und das Programm abbrechen, wenn die Werte nicht gültig sind. Dies geschieht hauptsächlich aus Sicherheitsgründen: Der Versuch, mit ungültigen Daten zu operieren, kann deinen Code Schwachstellen aussetzen. Dies ist der Hauptgrund dafür, dass die Standardbibliothek panic! aufruft, wenn du versuchst, einen unzulässigen Speicherzugriff durchzuführen: Der Versuch, auf Speicher zuzugreifen, der nicht zur aktuellen Datenstruktur gehört, ist ein häufiges Sicherheitsproblem. Funktionen haben oft Verträge (contracts): Ihr Verhalten ist nur dann garantiert, wenn die Eingaben bestimmte Anforderungen erfüllen. Abzubrechen, wenn der Vertrag verletzt wird, ist sinnvoll, weil eine Vertragsverletzung immer auf einen Fehler auf der Aufruferseite hinweist und es sich nicht um eine Fehlerart handelt, die der aufgerufende Code explizit behandeln sollte. Tatsächlich gibt es keinen vernünftigen Weg, wie sich der aufrufende Code vom Fehler erholen kann; die aufrufenden Programmierer müssen den Code reparieren. Verträge zu einer Funktion sollten in der API-Dokumentation der Funktion erläutert werden, insbesondere wenn deren Verletzung zu einem Programmabbruch führt.

Zahlreiche Fehlerprüfungen in deinen Funktionen wären jedoch langatmig und störend. Glücklicherweise kannst du das Typsystem von Rust (und damit die Typprüfung durch den Compiler) verwenden, um viele Prüfungen für dich zu übernehmen. Wenn deine Funktion einen besonderen Typ als Parameter hat, kannst du mit der Logik deines Codes fortfahren, da du weißt, dass der Compiler bereits sichergestellt hat, dass du einen gültigen Wert hast. Wenn du zum Beispiel einen Typ anstatt einer Option hast, erwartet dein Programm etwas statt nichts. Dein Code muss dann nicht zwei Fälle für die Varianten Some und None behandeln: Er wird nur einen Fall mit definitiv einem Wert haben. Code, der versucht, nichts an deine Funktion zu übergeben, lässt sich nicht einmal kompilieren, sodass deine Funktion diesen Fall zur Laufzeit nicht prüfen muss. Ein anderes Beispiel ist die Verwendung eines vorzeichenlosen Ganzzahl-Typs wie u32, der sicherstellt, dass der Parameter niemals negativ ist.

Benutzerdefinierte Typen für die Validierung erstellen

Gehen wir noch einen Schritt weiter, indem wir das Typsystem von Rust verwenden, um sicherzustellen, dass wir einen gültigen Wert haben, und betrachten wir die Erstellung eines benutzerdefinierten Typs für die Validierung. Erinnere dich an das Ratespiel in Kapitel 2, bei dem unser Code den Benutzer aufforderte, eine Zahl zwischen 1 und 100 zu erraten. Wir haben nie überprüft, ob die Schätzung des Benutzers zwischen diesen Zahlen lag, bevor wir sie mit unserer Geheimzahl verglichen haben; wir haben nur überprüft, ob die Schätzung richtig war. In diesem Fall waren die Folgen nicht sehr gravierend: Unsere Ausgabe von „zu groß“ oder „zu klein“ wäre immer noch richtig. Aber es wäre eine nützliche Erweiterung, um den Benutzer zu gültigen Rateversuchen zu führen und ein unterschiedliches Verhalten zu zeigen, wenn ein Benutzer eine Zahl eingibt, die außerhalb des Bereichs liegt, als wenn ein Benutzer stattdessen z.B. Buchstaben eingibt.

Eine Möglichkeit, dies zu tun, wäre, die Eingabe als i32 statt nur als u32 zu parsen, um potenziell negative Zahlen zuzulassen, und dann eine Bereichsprüfung der Zahl zu ergänzen, etwa so:

use rand::Rng;
use std::cmp::Ordering;
use std::io;

fn main() {
    println!("Rate eine Zahl!");

    let secret_number = rand::thread_rng().gen_range(1, 101);

    loop {
        // --abschneiden--

        println!("Bitte gib deine Vermutung ein.");

        let mut guess = String::new();

        io::stdin()
            .read_line(&mut guess)
            .expect("Fehler beim Lesen der Zeile");

        let guess: i32 = match guess.trim().parse() {
            Ok(num) => num,
            Err(_) => continue,
        };

        if guess < 1 || guess > 100 {
            println!("Die geheime Zahl wird zwischen 1 und 100 liegen.");
            continue;
        }

        match guess.cmp(&secret_number) {
            // --abschneiden--
            Ordering::Less => println!("Zu klein!"),
            Ordering::Greater => println!("Zu groß!"),
            Ordering::Equal => {
                println!("Du hast gewonnen!");
                break;
            }
        }
    }
}

Der if-Ausdruck prüft, ob unser Wert außerhalb des Bereichs liegt, informiert den Benutzer über das Problem und ruft continue auf, um die nächste Iteration der Schleife zu starten und um eine weitere Schätzung zu bitten. Nach dem if-Ausdruck können wir mit dem Vergleich zwischen guess und der Geheimzahl fortfahren, wobei wir wissen, dass guess zwischen 1 und 100 liegt.

Dies ist jedoch keine ideale Lösung: Wenn es zwingend erforderlich wäre, dass das Programm nur mit Werten zwischen 1 und 100 arbeitet, und wir viele Funktionen mit dieser Anforderung haben, wäre eine solche Prüfung in jeder Funktion mühsam (und könnte die Leistung beeinträchtigen).

Stattdessen können wir einen neuen Typ erstellen und die Validierungen in eine Funktion geben, um eine Instanz des Typs zu erzeugen, anstatt die Validierungen überall zu wiederholen. Auf diese Weise ist es für die Funktionen sicher, den neuen Typ in ihren Signaturen zu verwenden und die erhaltenen Werte bedenkenlos zu nutzen. Codeblock 9-13 zeigt eine Möglichkeit, einen Typ Guess zu definieren, der nur dann eine Instanz von Guess erzeugt, wenn die Funktion new einen Wert zwischen 1 und 100 erhält.

#![allow(unused)]
fn main() {
pub struct Guess {
    value: i32,
}

impl Guess {
    pub fn new(value: i32) -> Guess {
        if value < 1 || value > 100 {
            panic!("Der Schätzwert muss zwischen 1 und 100 liegen, ist jedoch {}.",
                   value);
        }

        Guess { value }
    }

    pub fn value(&self) -> i32 {
        self.value
    }
}
}

Codeblock 9-13: Ein Typ Guess, der nur bei Werten zwischen 1 und 100 fortsetzt

Zuerst definieren wir eine Struktur Guess, die ein Feld value hat, das einen i32 enthält. Hier wird die Nummer gespeichert.

Dann implementieren wir die zugehörige Funktion new für Guess, die Instanzen von Guess erzeugt. Die Funktion new ist so definiert, dass sie einen Parameter value vom Typ i32 entgegen nimmt und eine Guess-Instanz zurückgibt. Der Code im Funktionsrumpf von new testet den Wert in value, um sicherzustellen, dass er zwischen 1 und 100 liegt. Wenn value diesen Test nicht besteht, rufen wir panic! auf, was den Programmierer des aufrufenden Codes darauf aufmerksam macht, dass er einen Fehler hat, den er beheben muss, denn ein Guess mit einem Wert außerhalb dieses Bereichs zu erzeugen, würde den Vertrag verletzen, auf den sich Guess::new verlässt. Die Bedingungen, unter denen Guess::new das Programm abbricht, sollten in der öffentlich zugänglichen API-Dokumentation genannt werden; wir werden die Dokumentationskonventionen, die auf die Möglichkeit eines panic!-Aufrufs hinweisen, in der API-Dokumentation behandeln, die du in Kapitel 14 erstellst. Wenn value den Test besteht, erstellen wir eine neue Guess-Instanz, deren Feld value den Parameterwert value erhält, und geben die Instanz zurück.

Als nächstes implementieren wir eine Methode namens value, die self ausleiht, keine anderen Parameter hat und ein i32 zurückgibt. Diese Methodenart wird manchmal als Abfragemethode (getter) bezeichnet, weil ihr Zweck darin besteht, Daten aus ihren Feldern zurückzugeben. Diese öffentliche Methode ist notwendig, weil das Feld value der Struktur Guess privat ist. Es ist wichtig, dass das Feld value privat ist, damit Code, der die Struktur Guess verwendet, value nicht direkt setzen kann: Code außerhalb des Moduls muss die Funktion Guess::new verwenden, um eine Instanz von Guess zu erzeugen, wodurch sichergestellt wird, dass es keine Möglichkeit gibt, dass Guess einen Wert hat, der nicht durch die Bedingungen in der Funktion Guess::new überprüft wurde.

Eine Funktion, die einen Parameter hat oder nur Zahlen zwischen 1 und 100 zurückgibt, könnte dann in ihrer Signatur angeben, dass sie ein Guess anstelle eines i32 entgegennimmt oder zurückgibt und bräuchte dann in ihrem Rumpf keine zusätzlichen Prüfungen durchzuführen.

Zusammenfassung

Die Fehlerbehandlungsfunktionen von Rust sollen dir helfen, robusteren Code zu schreiben. Das Makro panic! signalisiert, dass sich dein Programm in einem Zustand befindet, mit dem es nicht umgehen kann, und ermöglicht es dir, den Prozess anzuhalten, anstatt zu versuchen, mit ungültigen oder falschen Werten fortzufahren. Die Aufzählung Result verwendet das Typsystem von Rust, um anzuzeigen, dass Operationen so fehlschlagen könnten, dass dein Code sich davon wieder erholen könnte. Du kannst Result verwenden, um dem Code, der deinen Code aufruft, mitzuteilen, dass er auch mit potentiellem Erfolg und Misserfolg umgehen muss. Das Verwenden von panic! und Result in den entsprechenden Situationen wird deinen Code angesichts unvermeidlicher Probleme zuverlässiger machen.

Nachdem du nun nützliche Möglichkeiten gesehen hast, wie die Standardbibliothek generische Datentypen mit den Enums Option und Result verwendet, werden wir darüber sprechen, wie generische Datentypen funktionieren und wie du sie in deinem Code verwenden kannst.

Generische Typen, Merkmale (traits) und Lebensdauer

Jede Programmiersprache verfügt über Werkzeuge, mit denen die Duplizierung von Konzepten (duplication of concepts) effektiv gehandhabt werden kann. In Rust ist ein solches Werkzeug der generische Datentyp (generics): Abstrakte Stellvertreter für konkrete Typen oder andere Eigenschaften. Wir können das Verhalten generischer Datentypen oder ihre Beziehung zu anderen generischen Datentypen ausdrücken, ohne zu wissen, was an ihrer Stelle beim Kompilieren und Ausführen des Codes stehen wird.

Funktionen können Parameter eines generischen Typs anstelle eines konkreten Typs wie i32 oder String annehmen, so wie eine Funktion Parameter mit unbekannten Werten annimmt, um denselben Code auf mehrere konkrete Werte anzuwenden. Tatsächlich haben wir generische Datentypen bereits in Kapitel 6 mit Option<T>, in Kapitel 8 mit Vec<T> und HashMap<K, V> und in Kapitel 9 mit Result<T, E> verwendet. In diesem Kapitel erfährst du, wie du deine eigenen Typen, Funktionen und Methoden mit generischen Datentypen definieren kannst!

Zunächst werden wir uns anschauen, wie eine Funktion extrahiert werden kann, um Code-Duplizierung zu reduzieren. Danach verwenden wir dieselbe Technik, um aus zwei Funktionen, die sich nur im Datentyp ihrer Parameter unterscheiden, eine generische Funktion zu machen. Wir werden auch erklären, wie generische Typen in Struktur- (struct) und Aufzählungsdefinitionen (enum) verwendet werden können.

Dann wirst du lernen, wie man Merkmale (traits) verwendet, um Verhalten auf generische Weise zu definieren. Du kannst Merkmale mit generischen Typen kombinieren, um einen generischen Typ auf solche Typen einzuschränken, die ein bestimmtes Verhalten aufweisen, im Gegensatz zu einem beliebigen Typ.

Schließlich werden wir die Lebensdauer (lifetimes) besprechen: Eine Spielart generischer Typen, die dem Compiler Informationen darüber gibt, wie Referenzen zueinander in Beziehung stehen. Lebensdauern ermöglichen es uns, dem Compiler genügend Informationen über ausgeliehene Werte zu geben, sodass er sicherstellen kann, dass Referenzen in mehr Situationen gültig sind, als er es ohne unsere Hilfe könnte.

Duplikate entfernen durch Extrahieren einer Funktion

Mit Hilfe von generischen Typen können wir spezifische Typen durch einen Platzhalter ersetzen, der mehrere Typen repräsentiert, um Code-Duplizierung zu vermeiden. Bevor wir uns mit der generischen Syntax befassen, wollen wir uns zunächst ansehen, wie man Duplikate auf eine Weise entfernt, die keine generischen Typen erfordert, indem man eine Funktion extrahiert, die spezifische Werte durch einen Platzhalter ersetzt, der mehrere Werte repräsentiert. Dann wenden wir die gleiche Technik an, um eine generische Funktion zu extrahieren! Wenn du dir ansiehst, wie du doppelten Code erkennst, den du in eine Funktion extrahieren kannst, wirst du beginnen, doppelten Code zu erkennen, der generische Typen verwenden kann.

Wir beginnen mit dem kurzen Programm in Codeblock 10-1, das die größte Zahl in einer Liste findet.

Dateiname: src/main.rs

fn main() {
    let number_list = vec![34, 50, 25, 100, 65];

    let mut largest = number_list[0];

    for number in number_list {
        if number > largest {
            largest = number;
        }
    }

    println!("Die größte Zahl ist {}", largest);
    assert_eq!(largest, 100);
}

Codeblock 10-1: Finden der größten Zahl in einer Liste von Zahlen

Wir speichern eine Liste von ganzen Zahlen in der Variablen number_list und weisen eine Referenz der ersten Zahl der Liste einer Variablen namens largest zu. Dann iterieren wir über alle Zahlen in der Liste und wenn die aktuelle Zahl größer als die in largest gespeicherte Zahl ist, ersetzen wir die Referenz in dieser Variablen. Wenn die aktuelle Zahl jedoch kleiner oder gleich der größten bisher gefundenen Zahl ist, ändert sich die Variable nicht, und der Code geht zur nächsten Zahl in der Liste weiter. Nach dem Durchlaufen aller Zahlen in der Liste sollte largest auf die größte Zahl referenzieren, in diesem Fall 100.

Wir haben nun die Aufgabe bekommen, die größte Zahl in zwei verschiedenen Zahlenlisten zu finden. Zu diesem Zweck können wir den Code in Codeblock 10-1 duplizieren und dieselbe Logik an zwei verschiedenen Stellen im Programm verwenden, wie in Codeblock 10-2 gezeigt.

Dateiname: src/main.rs

fn main() {
    let number_list = vec![34, 50, 25, 100, 65];

    let mut largest = number_list[0];

    for number in number_list {
        if number > largest {
            largest = number;
        }
    }

    println!("Die größte Zahl ist {}", largest);

    let number_list = vec![102, 34, 6000, 89, 54, 2, 43, 8];

    let mut largest = number_list[0];

    for number in number_list {
        if number > largest {
            largest = number;
        }
    }

    println!("Die größte Zahl ist {}", largest);
}

Codeblock 10-2: Code zum Auffinden der größten Zahl in zwei Zahlenlisten

Obwohl dieser Code funktioniert, ist das Duplizieren von Code mühsam und fehleranfällig. Außerdem müssen wir daran denken, den Code an mehreren Stellen zu aktualisieren, wenn wir ihn ändern wollen.

Um diese Redundanz zu eliminieren, können wir eine Abstraktion schaffen, indem wir eine Funktion definieren, die auf einer beliebigen Liste ganzer Zahlen operiert, die ihr als Parameter übergeben wird. Diese Lösung macht unseren Code klarer und lässt uns das Konzept, die größte Zahl in einer Liste zu finden, abstrakter ausdrücken.

In Codeblock 10-3 extrahieren wir den Code, der die größte Zahl findet, in eine Funktion namens largest. Dann rufen wir die Funktion auf, um die größte Zahl in den beiden Listen aus Codeblock 10-2 zu finden. Wir könnten die Funktion auch auf jede andere Liste von i32-Werten anwenden, die wir in Zukunft haben könnten.

Dateiname: src/main.rs

fn largest(list: &[i32]) -> i32 {
    let mut largest = list[0];

    for &item in list {
        if item > largest {
            largest = item;
        }
    }

    largest
}

fn main() {
    let number_list = vec![34, 50, 25, 100, 65];

    let result = largest(&number_list);
    println!("Die größte Zahl ist {}", result);
    assert_eq!(result, 100);

    let number_list = vec![102, 34, 6000, 89, 54, 2, 43, 8];

    let result = largest(&number_list);
    println!("Die größte Zahl ist {}", result);
    assert_eq!(result, 6000);
}

Codeblock 10-3: Abstrahierter Code, um die größte Zahl in zwei Listen zu finden

Die Funktion largest hat einen Parameter list, der einen beliebigen Anteilstyp von i32-Werten repräsentiert, die wir an die Funktion übergeben könnten. Wenn wir die Funktion aufrufen, läuft der Code also auf den spezifischen Werten, die wir übergeben.

Zusammenfassend hier die Schritte, die wir unternommen haben, um den Code aus Codeblock 10-2 in Codeblock 10-3 zu überführen:

1. Identifiziere doppelten Code.
2. Extrahiere den doppelten Code in den Funktionskörper und spezifiziere die Eingabe- und Rückgabewerte dieses Codes in der Funktionssignatur.
3. Aktualisiere die beiden Instanzen des doppelten Codes, um stattdessen die Funktion aufzurufen.

Als Nächstes werden wir dieselben Schritte auf generische Datentypen anwenden, um doppelten Code zu reduzieren. Ähnlich wie der Funktionsrumpf auf einer abstrakten Liste anstelle spezifischer Werte arbeiten kann, erlauben es generische Datentypen, auf abstrakten Typen zu arbeiten.

Nehmen wir zum Beispiel an, wir hätten zwei Funktionen: Eine, die das größte Element in einem Anteilstyp mit i32-Werten findet, und eine, die das größte Element in einem Anteilstyp mit char-Werten findet. Wie würden wir diese Duplizierung beseitigen? Lass es uns herausfinden!

Generische Datentypen

Wir verwenden generische Datentypen (generics), um Definitionen für Elemente wie Funktionssignaturen oder Strukturen (structs) zu erstellen, die wir dann mit vielen verschiedenen konkreten Datentypen verwenden können. Sehen wir uns zunächst an, wie Funktionen, Strukturen, Aufzählungen und Methoden mithilfe von generischen Datentypen definiert werden können. Danach werden wir uns ansehen, wie generische Datentypen die Code-Performanz beeinflussen.

In Funktionsdefinitionen

Bei der Definition einer Funktion, die generische Datentypen verwendet, platzieren wir die generischen Datentypen in der Signatur der Funktion, wo wir normalerweise die Datentypen der Parameter und des Rückgabewerts angeben würden. Dadurch wird unser Code flexibler und bietet den Aufrufern unserer Funktion mehr Funktionalität, während gleichzeitig Code-Duplikate verhindert werden.

Um mit unserer Funktion largest fortzufahren, zeigt Codeblock 10-4 zwei Funktionen, die beide den größten Wert in einem Anteilstyp finden. Wir werden diese dann in einer einzigen Funktion kombinieren, die generische Typen verwendet.

Dateiname: src/main.rs

fn largest_i32(list: &[i32]) -> i32 {
    let mut largest = list[0];

    for &item in list {
        if item > largest {
            largest = item;
        }
    }

    largest
}

fn largest_char(list: &[char]) -> char {
    let mut largest = list[0];

    for &item in list {
        if item > largest {
            largest = item;
        }
    }

    largest
}

fn main() {
    let number_list = vec![34, 50, 25, 100, 65];

    let result = largest_i32(&number_list);
    println!("Die größte Zahl ist {}", result);
    assert_eq!(result, 100);

    let char_list = vec!['y', 'm', 'a', 'q'];

    let result = largest_char(&char_list);
    println!("Das größte Zeichen ist {}", result);
    assert_eq!(result, 'y');
}

Codeblock 10-4: Zwei Funktionen, die sich nur in ihren Namen und den Typen in ihren Signaturen unterscheiden

Die Funktion largest_i32 ist diejenige, die wir in Codeblock 10-3 extrahiert haben und die den größten i32 in einem Anteilstyp findet. Die Funktion largest_char findet das größte char in einem Anteilstyp. Die Funktionsrümpfe haben den gleichen Code, also lass uns die Duplizierung eliminieren, indem wir einen generischen Typparameter in einer einzigen Funktion einführen.

Um die Typen in einer neuen, einzigen Funktion zu parametrisieren, müssen wir den Typparameter benennen, so wie wir es für die Wertparameter einer Funktion tun. Du kannst jeden beliebigen Bezeichner als Typparametername verwenden. Aber wir werden T verwenden, weil die Typparameternamen gemäß Konvention in Rust kurz sind, oft nur ein Buchstabe, und Rusts Typbezeichnungskonvention verwendet Binnenmajuskel (UpperCamelCase). Als Abkürzung für „Typ“ ist T die Standardwahl der meisten Rust-Programmierer.

Wenn wir einen Parameter im Funktionsrumpf verwenden, müssen wir den Parameternamen in der Signatur deklarieren, damit der Compiler weiß, was dieser Name bedeutet. In ähnlicher Weise müssen wir den Typ-Parameternamen deklarieren, bevor wir ihn in einer Funktionssignatur verwenden können. Um die generische Funktion largest zu definieren, platzieren wir die Typnamen-Deklarationen innerhalb spitzer Klammern <>, zwischen dem Funktionsnamen und der Parameterliste, so wie hier:

fn largest<T>(list: &[T]) -> &T {

Wir lesen diese Definition wie folgt: Die Funktion largest ist generisch über einen Typ T. Sie hat einen Parameter namens list, der ein Anteilstyp von Werten des Typs T ist. Die Funktion largest gibt eine Referenz auf denn Wert des gleichen Typs T zurück.

Codeblock 10-5 zeigt die kombinierte Funktionsdefinition largest, die den generischen Datentyp in ihrer Signatur verwendet. Der Codeblock zeigt auch, wie wir die Funktion entweder mit einem Anteilstyp von i32-Werten oder char-Werten aufrufen können. Beachte, dass sich dieser Code noch nicht kompilieren lässt, aber wir werden das Problem später in diesem Kapitel beheben.

Dateiname: src/main.rs

fn largest<T>(list: &[T]) -> &T {
    let mut largest = &list[0];

    for item in list {
        if item > largest {
            largest = item;
        }
    }

    largest
}

fn main() {
    let number_list = vec![34, 50, 25, 100, 65];

    let result = largest(&number_list);
    println!("Die größte Zahl ist {}", result);

    let char_list = vec!['y', 'm', 'a', 'q'];

    let result = largest(&char_list);
    println!("Das größte Zeichen ist {}", result);
}

Codeblock 10-5: Die Funktion largest mit generischen Typparametern; diese kompiliert aber noch nicht

Wenn wir diesen Code kompilieren, erhalten wir diesen Fehler:

$ cargo run
   Compiling chapter10 v0.1.0 (file:///projects/chapter10)
error[E0369]: binary operation `>` cannot be applied to type `&T`
 --> src/main.rs:5:17
  |
5 |         if item > largest {
  |            ---- ^ ------- &T
  |            |
  |            &T
  |
help: consider restricting type parameter `T`
  |
1 | fn largest<T: std::cmp::PartialOrd>(list: &[T]) -> &T {
  |             ++++++++++++++++++++++

For more information about this error, try `rustc --explain E0369`.
error: could not compile `chapter10` (bin "chapter10") due to 1 previous error

Der Hilfetext erwähnt std::cmp::PartialOrd, was ein Merkmal (trait) ist, und wir werden im nächsten Abschnitt über Merkmale sprechen. Vorerst bedeutet dieser Fehler, dass der Rumpf von largest nicht für alle möglichen Typen funktioniert, die T sein könnten. Da wir Werte des Typs T im Rumpf vergleichen wollen, können wir nur Typen verwenden, deren Werte sortiert werden können. Um Vergleiche zu ermöglichen, hat die Standardbibliothek das Merkmal std::cmp::PartialOrd, das du auf Typen implementieren kannst (siehe Anhang C für weitere Informationen zu diesem Merkmal). Indem wir dem Vorschlag des Hilfetextes folgen, schränken wir die für T gültigen Typen auf diejenigen ein, die PartialOrd implementieren und dieses Beispiel kompiliert, weil die Standardbibliothek PartialOrd sowohl auf i32 als auch auf char implementiert.

In Struktur-Definitionen

Wir können auch Strukturen definieren, um einen generischen Typparameter in einem oder mehreren Feldern mit der <> Syntax zu verwenden. Codeblock 10-6 definiert eine Struktur Point<T>, um Koordinatenwerte x und y eines beliebigen Typs aufzunehmen.

Dateiname: src/main.rs

struct Point<T> {
    x: T,
    y: T,
}

fn main() {
    let integer = Point { x: 5, y: 10 };
    let float = Point { x: 1.0, y: 4.0 };
}

Codeblock 10-6: Eine Struktur Point<T>, die Werte x und y vom Typ T enthält

Die Syntax zum Verwenden von generischen Datentypen in Strukturdefinitionen ähnelt der Syntax, die in Funktionsdefinitionen verwendet wird. Zuerst deklarieren wir den Namen des Typparameters innerhalb spitzer Klammern direkt nach dem Namen der Struktur. Dann verwenden wir den generischen Typ in der Strukturdefinition, wo wir sonst konkrete Datentypen angeben würden.

Beachte, da wir nur einen generischen Typ zur Definition von Point<T> verwendet haben, besagt diese Definition, dass die Struktur Point<T> generisch über einen Typ T ist, und die beiden Felder x und y denselben Typ haben, welcher Typ das auch immer sein mag. Wenn wir eine Instanz von Point<T> erzeugen, die Werte unterschiedlichen Typs hat, wie in Codeblock 10-7, wird sich unser Code nicht kompilieren lassen.

Dateiname: src/main.rs

struct Point<T> {
    x: T,
    y: T,
}

fn main() {
    let wont_work = Point { x: 5, y: 4.0 };
}

Codeblock 10-7: Die Felder x und y müssen vom gleichen Typ sein, da beide den gleichen generischen Datentyp T haben.

Wenn wir in diesem Beispiel x den Integer-Wert 5 zuweisen, lassen wir den Compiler wissen, dass der generische Typ T für diese Instanz von Point<T> ein Integer sein wird. Wenn wir dann 4.0 für y angeben, das wir so definiert haben, dass es den gleichen Typ wie x hat, erhalten wir einen Typfehler wie diesen:

$ cargo run
   Compiling chapter10 v0.1.0 (file:///projects/chapter10)
error[E0308]: mismatched types
 --> src/main.rs:7:38
  |
7 |     let wont_work = Point { x: 5, y: 4.0 };
  |                                      ^^^ expected integer, found floating-point number

For more information about this error, try `rustc --explain E0308`.
error: could not compile `chapter10` (bin "chapter10") due to 1 previous error

Um eine Struktur Point zu definieren, bei der x und y generische, aber unterschiedliche, Typen haben können, können wir mehrere generische Typparameter verwenden. Zum Beispiel ändern wir in Codeblock 10-8 die Definition von Point so, dass sie über den Typen T und U generisch ist, wobei x vom Typ T und y vom Typ U ist.

Dateiname: src/main.rs

struct Point<T, U> {
    x: T,
    y: U,
}

fn main() {
    let both_integer = Point { x: 5, y: 10 };
    let both_float = Point { x: 1.0, y: 4.0 };
    let integer_and_float = Point { x: 5, y: 4.0 };
}

Codeblock 10-8: Point<T, U> ist generisch über zwei Typen, sodass x und y Werte unterschiedlichen Typs haben können

Jetzt sind alle gezeigten Instanzen von Point erlaubt! Du kannst so viele generische Typparameter in einer Definition verwenden, wie du willst, aber das Verwenden von mehr als einigen wenigen macht deinen Code schwer lesbar. Wenn du denkst, dass du in deinem Code viele generische Typen benötigst, könnte dies darauf hinweisen, dass dein Code in kleinere Teile zerlegt werden muss.

In Aufzählungsdefinitionen

Wie wir es bei Strukturen gemacht haben, können wir Aufzählungen definieren, um generische Datentypen in ihren Varianten zu verwenden. Werfen wir noch einmal einen Blick auf die Aufzählung Option<T>, die die Standardbibliothek bietet und die wir in Kapitel 6 verwendet haben:

#![allow(unused)]
fn main() {
enum Option<T> {
    Some(T),
    None,
}
}

Diese Definition dürfte für dich jetzt mehr Sinn machen. Wie du sehen kannst, ist die Aufzählung Option<T> über dem Typ T generisch und hat zwei Varianten: Some, die einen Wert vom Typ T enthält, und None, die keinen Wert enthält. Durch das Verwenden der Aufzählung Option<T> können wir das abstrakte Konzept eines optionalen Wertes ausdrücken und da Option<T> generisch ist, können wir diese Abstraktion unabhängig vom Typ des optionalen Wertes verwenden.

Aufzählungen können auch mehrere generische Typen verwenden. Die Definition der Aufzählung Result, die wir in Kapitel 9 verwendet haben, ist ein Beispiel dafür:

#![allow(unused)]
fn main() {
enum Result<T, E> {
    Ok(T),
    Err(E),
}
}

Die Aufzählung Result ist generisch über zwei Typen T und E und hat zwei Varianten: Ok, die einen Wert vom Typ T enthält, und Err, die einen Wert vom Typ E enthält. Diese Definition macht es bequem, die Aufzählung Result überall dort zu verwenden, wo wir eine Operation haben, die erfolgreich sein (gibt einen Wert vom Typ T zurück) oder fehlschlagen (gibt einen Fehler vom Typ E zurück) könnte. Tatsächlich haben wir dies beim Öffnen einer Datei in Codeblock 9-3 verwendet, wobei für T der Typ std::fs::File verwendet wurde, wenn die Datei erfolgreich geöffnet wurde, und für E der Typ std::io::Error, wenn es Probleme beim Öffnen der Datei gab.

Wenn du in deinem Code Situationen mit mehreren Struktur- oder Aufzählungsdefinitionen erkennst, die sich nur in den Typen der darin enthaltenen Werte unterscheiden, kannst du doppelten Code vermeiden, indem du stattdessen generische Typen verwendest.

In Methodendefinitionen

Wir können Methoden auf Strukturen und Aufzählungen implementieren (wie wir es in Kapitel 5 getan haben) und auch generische Typen in ihren Definitionen verwenden. Codeblock 10-9 zeigt die Struktur Point<T>, die wir in Codeblock 10-6 definiert haben, mit einer darauf implementierten Methode namens x.

Dateiname: src/main.rs

struct Point<T> {
    x: T,
    y: T,
}

impl<T> Point<T> {
    fn x(&self) -> &T {
        &self.x
    }
}

fn main() {
    let p = Point { x: 5, y: 10 };

    println!("p.x = {}", p.x());
}

Codeblock 10-9: Implementierung einer Methode x auf der Struktur Point<T>, die eine Referenz auf das Feld x vom Typ T zurückgibt

Hier haben wir eine Methode x auf Point<T> definiert, die eine Referenz auf den Wert im Feld x zurückgibt.

Beachte, dass wir T direkt nach impl deklarieren müssen, damit wir Methoden zum Typ Point<T> implementieren können. Durch das Deklarieren von T als generischen Typ hinter impl kann Rust erkennen, dass der Typ in spitzen Klammern in Point ein generischer und kein konkreter Typ ist. Wir hätten einen anderen Namen für den generischen Parameter wählen können als den in der Strukturdefinition deklarierten generischen Parameter, aber die Verwendung desselben Namens ist üblich. Methoden, die innerhalb eines impl geschrieben werden, das den generischen Typ deklariert, werden auf jeder Instanz des Typs definiert, unabhängig davon, welcher konkrete Typ am Ende den generischen Typ ersetzt.

Wir können auch Einschränkungen für generische Typen angeben, wenn wir Methoden auf dem Typ definieren. Wir könnten zum Beispiel Methoden nur auf Point<f32>-Instanzen implementieren und nicht auf Point<T>-Instanzen mit einem beliebigen generischen Typ. In Codeblock 10-10 verwenden wir den konkreten Typ f32, d.h. wir deklarieren keinen Typ hinter impl.

Dateiname: src/main.rs

struct Point<T> {
    x: T,
    y: T,
}

impl<T> Point<T> {
    fn x(&self) -> &T {
        &self.x
    }
}

impl Point<f32> {
    fn distance_from_origin(&self) -> f32 {
        (self.x.powi(2) + self.y.powi(2)).sqrt()
    }
}

fn main() {
    let p = Point { x: 5, y: 10 };

    println!("p.x = {}", p.x());
}

Codeblock 10-10: Ein impl-Block, der nur für eine Struktur mit einem bestimmten konkreten Typ für den generischen Typparameter T gilt

Dieser Code bedeutet, dass der Typ Point<f32> eine Methode distance_from_origin hat und andere Instanzen von Point<T>, bei denen T nicht vom Typ f32 ist, haben diese Methode nicht. Die Methode misst, wie weit unser Punkt vom Punkt mit den Koordinaten (0,0, 0,0) entfernt ist, und verwendet mathematische Operationen, die nur für Fließkomma-Typen zur Verfügung stehen.

Generische Typparameter in einer Strukturdefinition sind nicht immer die gleichen wie die, die du in denselben Methodensignaturen für diese Struktur verwendest. In Codeblock 10-11 werden die generischen Typen X1 und Y1 für die Struktur Point und X2 und Y2 für die Signatur der Methode mixup verwendet, um das Beispiel zu verdeutlichen. Die Methode erzeugt eine neue Point-Instanz mit dem Wert x aus self (vom Typ X1) und dem Wert y aus dem übergebenen Point (vom Typ Y2).

Dateiname: src/main.rs

struct Point<X1, Y1> {
    x: X1,
    y: Y1,
}

impl<X1, Y1> Point<X1, Y1> {
    fn mixup<X2, Y2>(self, other: Point<X2, Y2>) -> Point<X1, Y2> {
        Point {
            x: self.x,
            y: other.y,
        }
    }
}

fn main() {
    let p1 = Point { x: 5, y: 10.4 };
    let p2 = Point { x: "Hallo", y: 'c' };

    let p3 = p1.mixup(p2);

    println!("p3.x = {}, p3.y = {}", p3.x, p3.y);
}

Codeblock 10-11: Eine Methode, die generische Typen aus der Definition ihrer Struktur anders verwendet

In main haben wir einen Point definiert, bei dem x den Typ i32 (mit dem Wert 5) und y den Typ f64 (mit dem Wert 10.4) hat. Die Variable p2 ist eine Struktur Point, bei der x einen Zeichenkettenanteilstyp (mit dem Wert "Hallo") und y den Typ char (mit dem Wert c) hat. Wenn wir mixup auf p1 mit dem Argument p2 aufrufen, erhalten wir p3, das ein i32 für x haben wird, weil x von p1 kam. Die Variable p3 wird ein char für y haben, weil y von p2 stammt. Der Makroaufruf println! gibt p3.x = 5, p3.y = c aus.

Der Zweck dieses Beispiels ist es, eine Situation zu demonstrieren, in der einige generische Parameter mit impl und einige mit der Methodendefinition deklariert werden. Hier werden die generischen Parameter X1 und Y1 nach impl deklariert, weil sie zur Strukturdefinition gehören. Die generischen Parameter X2 und Y2 werden nach fn mixup deklariert, da sie nur für die Methode relevant sind.

Code-Performanz beim Verwenden generischer Datentypen

Du fragst dich vielleicht, ob beim Verwenden generischer Typparameter Laufzeitkosten anfallen. Die gute Nachricht ist, dass die Verwendung generischer Typen die Ausführung deines Programms nicht langsamer macht als bei konkreten Typen.

Rust erreicht dies durch Duplizierung von Code mit generischen Datentypen zur Kompilierzeit. Codeduplizierung (monomorphization) ist der Vorgang der Umwandlung von generischem Code in spezifischen Code durch Ausfüllen der konkreten Typen, die bei der Kompilierung verwendet werden. Bei diesem Vorgang führt der Compiler das Gegenteil der Schritte aus, die wir beim Erstellen der generischen Funktion in Codeblock 10-5 angewendet haben: Der Compiler schaut sich alle Stellen an, an denen generischer Code aufgerufen wird, und generiert Code für die konkreten Typen, mit denen der generische Code aufgerufen wird.

Betrachten wir die Funktionsweise bei der Aufzählung Option<T> der Standardbibliothek:

#![allow(unused)]
fn main() {
let integer = Some(5);
let float = Some(5.0);
}

Wenn Rust diesen Code kompiliert, führt es eine Codeduplizierung durch. Während dieses Vorgangs liest der Compiler die Werte ein, die in Option<T>-Instanzen verwendet wurden, und identifiziert zwei Arten von Option<T>: Eine verwendet den Typ i32 und die andere f64. Als solches erweitert es die allgemeine Definition von Option<T> in zwei auf i32 und f64 spezialisierte Definitionen, wodurch die allgemeine Definition durch die spezifische ersetzt wird.

Die duplizierte Codeversion sieht ähnlich aus wie die folgende (der Compiler verwendet andere Namen als die, die wir hier zur Veranschaulichung verwenden):

Dateiname: src/main.rs

enum Option_i32 {
    Some(i32),
    None,
}

enum Option_f64 {
    Some(f64),
    None,
}

fn main() {
    let integer = Option_i32::Some(5);
    let float = Option_f64::Some(5.0);
}

Der generische Typ Option<T> wird durch die vom Compiler erstellten spezifischen Definitionen ersetzt. Da Rust generischen Code in Code kompiliert, der den Typ in jedem Fall spezifiziert, zahlen wir keine Laufzeitkosten beim Verwenden von generischen Datentypen. Wenn der Code läuft, verhält er sich genauso, wie wenn wir jede Definition von Hand dupliziert hätten. Der Vorgang der Codeduplizierung macht Rusts generische Datentypen zur Laufzeit äußerst effizient.

Merkmale (traits): Gemeinsames Verhalten definieren

Ein Merkmal (trait) definiert Funktionalität, den ein bestimmter Typ hat und mit anderen Typen teilen kann. Wir können Merkmale verwenden, um gemeinsames Verhalten auf abstrakte Weise zu definieren. Wir können Merkmalsabgrenzungen (trait bounds) verwenden, um anzugeben, dass ein generischer Typ jeder Typ sein kann, der ein bestimmtes Verhalten aufweist.

Anmerkung: Merkmale sind einer Funktionalität recht ähnlich, die in anderen Sprachen oft Schnittstelle (interface) genannt wird, wenn auch mit einigen Unterschieden.

Ein Merkmal definieren

Das Verhalten eines Typs besteht aus den Methoden, die wir auf diesen Typ anwenden können. Verschiedene Typen haben das gleiche Verhalten, wenn wir bei allen die gleichen Methoden aufrufen können. Merkmalsdefinitionen sind eine Möglichkeit, Methodensignaturen zu gruppieren, um eine Reihe von Verhaltensweisen zu definieren, die zum Erreichen eines bestimmten Zwecks erforderlich sind.

Nehmen wir zum Beispiel an, wir haben mehrere Strukturen (structs), die verschiedene Arten und Mengen von Text enthalten: Eine Struktur NewsArticle, die eine Nachricht enthält, die sich auf einen bestimmten Ort bezieht, und ein Tweet, der maximal 280 Zeichen umfassen kann, sowie Metadaten, die angeben, ob es sich um eine neue Kurznachricht, eine Wiederholung oder eine Antwort auf eine andere Kurznachricht handelt.

Wir wollen eine Medienaggregator-Bibliothekskiste namens aggregator erstellen, die Zusammenfassungen von Daten anzeigen kann, die in einer NewsArticle- oder Tweet-Instanz gespeichert sein könnten. Dazu brauchen wir eine Zusammenfassung von jedem Typ, und wir werden diese Zusammenfassung anfordern, indem wir eine Methode summarize auf einer Instanz aufrufen. Codeblock 10-12 zeigt die Definition eines öffentlichen Summary-Merkmals, das dieses Verhalten zum Ausdruck bringt.

Dateiname: src/lib.rs

#![allow(unused)]
fn main() {
pub trait Summary {
    fn summarize(&self) -> String;
}
}

Codeblock 10-12: Ein Merkmal Summary, dessen Verhalten aus der Methode summarize besteht

Hier deklarieren wir ein Merkmal mit dem Schlüsselwort trait und dann den Namen des Merkmals, der in diesem Fall Summary lautet. Wir haben das Merkmal auch als pub deklariert, sodass Kisten, die von dieser Kiste abhängen, dieses Merkmal ebenfalls nutzen können, wie wir in einigen Beispielen sehen werden. Innerhalb der geschweiften Klammern deklarieren wir die Methodensignaturen, die das Verhalten der Typen beschreiben, die dieses Merkmal implementieren, was in diesem Fall fn summarize(&self) -> String ist.

Nach der Methodensignatur verwenden wir statt einer Implementierung in geschweiften Klammern ein Semikolon. Jeder Typ, der dieses Merkmal implementiert, muss sein eigenes benutzerdefiniertes Verhalten für den Methodenrumpf bereitstellen. Der Compiler wird sicherstellen, dass jeder Typ, der das Merkmal Summary hat, die Methode summarize mit genau dieser Signatur hat.

Ein Merkmal kann mehrere Methoden umfassen: Die Methodensignaturen werden zeilenweise aufgelistet und jede Zeile endet mit einem Semikolon.

Ein Merkmal für einen Typ implementieren

Nachdem wir nun die gewünschten Signaturen der Methoden des Merkmals Summary definiert haben, können wir sie für die Typen in unserem Medienaggregator implementieren. Codeblock 10-13 zeigt eine Implementierung des Merkmals Summary für die Struktur NewsArticle, die die Überschrift, den Autor und den Ort verwendet, um den Rückgabewert von summarize zu erzeugen. Für die Struktur Tweet definieren wir summarize als den Benutzernamen, gefolgt vom gesamten Text der Kurznachricht, wobei wir davon ausgehen, dass der Inhalt der Kurznachricht bereits auf 280 Zeichen begrenzt ist.

Dateiname: src/lib.rs

#![allow(unused)]
fn main() {
pub trait Summary {
    fn summarize(&self) -> String;
}

pub struct NewsArticle {
    pub headline: String,
    pub location: String,
    pub author: String,
    pub content: String,
}

impl Summary for NewsArticle {
    fn summarize(&self) -> String {
        format!("{}, von {} ({})", self.headline, self.author, self.location)
    }
}

pub struct Tweet {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub retweet: bool,
}

impl Summary for Tweet {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}
}

Codeblock 10-13: Implementierung des Merkmals Summary für die Typen NewsArticle und Tweet

Die Implementierung eines Merkmals für einen Typ ist ähnlich zur Implementierung regulärer Methoden. Der Unterschied besteht darin, dass wir nach impl den Namen des Merkmals schreiben, das wir implementieren wollen und dann das Schlüsselwort for gefolgt vom Namen des Typs, für den wir das Merkmal implementieren wollen. Innerhalb des impl-Blocks geben wir die Methodensignaturen an, die das Merkmal vorgibt. Anstatt nach jeder Signatur ein Semikolon zu schreiben, verwenden wir geschweifte Klammern und füllen den Methodenrumpf mit dem spezifischen Verhalten, das die Methoden des Merkmals für den jeweiligen Typ haben sollen.

Da die Bibliothek nun das Merkmal Summary auf NewsArticle und Tweet implementiert hat, können Benutzer der Kiste die Merkmals-Methoden auf Instanzen von NewsArticle und Tweet auf die gleiche Weise aufrufen, wie wir reguläre Methoden aufrufen. Der einzige Unterschied besteht darin, dass der Benutzer das Merkmal sowie die Typen in den Gültigkeitsbereich bringen muss, um die zusätzlichen Merkmals-Methoden zu erhalten. Hier ist ein Beispiel dafür, wie eine binäre Kiste unsere aggregator-Bibliothekskiste verwenden könnte:

use aggregator::{self, Summary, Tweet};

fn main() {
    let tweet = Tweet {
        username: String::from("horse_ebooks"),
        content: String::from(
            "natürlich, wie du wahrscheinlich schon weißt",
        ),
        reply: false,
        retweet: false,
    };

    println!("1 neue Kurznachricht: {}", tweet.summarize());
}

Dieser Code gibt 1 neue Kurznachricht: horse_ebooks: natürlich, wie du wahrscheinlich schon weißt aus.

Andere Kisten, die von der aggregator-Kiste abhängen, können auch das Merkmal Summary in den Gültigkeitsbereich bringen, um Summary auf ihren eigenen Typen zu implementieren. Eine Einschränkung ist, dass wir ein Merkmal für einen Typ nur dann implementieren können, wenn entweder das Merkmal oder der Typ lokal in unserer Kiste vorhanden ist. Zum Beispiel können wir Standard-Bibliotheksmerkmale wie Display auf einem benutzerdefinierten Typ wie Tweet als Teil unserer aggregator-Kistenfunktionalität implementieren, weil der Typ Tweet lokal zu unserer aggregator-Kiste gehört. Wir können auch Summary auf Vec<T> in unserer aggregator-Kiste implementieren, weil das Merkmal Summary lokal zu unserer aggregator-Kiste gehört.

Aber wir können externe Merkmale nicht auf externe Typen anwenden. Zum Beispiel können wir das Merkmal Display auf Vec<T> in unserer aggregator-Kiste nicht implementieren, weil Display und Vec<T> in der Standardbibliothek definiert sind und nicht lokal zu unserer aggregator-Kiste gehören. Diese Beschränkung ist Teil einer Eigenschaft von Programmen namens Kohärenz (coherence), genauer gesagt der Waisenregel (orphan rule), die so genannt wird, weil der übergeordnete Typ nicht vorhanden ist. Diese Regel stellt sicher, dass der Code anderer Personen deinen Code nicht brechen kann und umgekehrt. Ohne diese Regel könnten zwei Kisten dasselbe Merkmal für denselben Typ implementieren und Rust wüsste nicht, welche Implementierung es verwenden sollte.

Standard-Implementierungen

Manchmal ist es nützlich, ein Standardverhalten für einige oder alle Methoden eines Merkmals zu haben, anstatt Implementierungen für alle Methoden für jeden Typ zu verlangen. Wenn wir dann das Merkmal für einen bestimmten Typ implementieren, können wir das Standardverhalten jeder Methode beibehalten oder überschreiben.

In Codeblock 10-14 geben wir eine Standard-Zeichenkette für die Methode summarize des Merkmals Summary an, anstatt nur die Methodensignatur zu definieren, wie wir es in Codeblock 10-12 getan haben.

Dateiname: src/lib.rs

#![allow(unused)]
fn main() {
pub trait Summary {
    fn summarize(&self) -> String {
        String::from("(Lies mehr ...)")
    }
}
}

Codeblock 10-14: Definieren eines Merkmals Summary mit einer Standard-Implementierung der Methode summarize

Um eine Standard-Implementierung zu verwenden, um Instanzen von NewsArticle zusammenzufassen, geben wir einen leeren impl-Block mit impl Summary for NewsArticle {} an.

Auch wenn wir die Methode summarize nicht mehr direkt für NewsArticle definieren, haben wir eine Standard-Implementierung bereitgestellt und festgelegt, dass NewsArticle das Merkmal Summary implementiert. Infolgedessen können wir immer noch die Methode summarize einer NewsArticle-Instanz aufrufen, etwa so:

use aggregator::{self, NewsArticle, Summary};

fn main() {
    let article = NewsArticle {
        headline: String::from("Penguins gewinnen die Stanley-Cup-Meisterschaft!"),
        location: String::from("Pittsburgh, PA, USA"),
        author: String::from("Iceburgh"),
        content: String::from("Die Pittsburgh Penguins sind erneut die beste \
                               Eishockeymannschaft in der NHL.",
        ),
    };

    println!("Neuer Artikel verfügbar! {}", article.summarize());
}

Dieser Code gibt Neuer Artikel verfügbar! (Lies mehr ...) aus.

Das Erstellen einer Standard-Implementierung erfordert nicht, dass wir an der Implementierung von Summary für Tweet in Codeblock 10-13 etwas ändern. Der Grund dafür ist, dass die Syntax für das Überschreiben einer Standard-Implementierung die gleiche ist wie die Syntax für die Implementierung einer Merkmalsmethode, die keine Standard-Implementierung hat.

Standard-Implementierungen können andere Methoden desselben Merkmals aufrufen, selbst wenn diese anderen Methoden keine Standard-Implementierung haben. Auf diese Weise kann ein Merkmal eine Menge nützlicher Funktionalität bereitstellen und von den Implementierern nur die Angabe eines kleinen Teils verlangen. Zum Beispiel könnten wir das Merkmal Summary so definieren, dass wir eine Methode summarize_author haben, deren Implementierung erforderlich ist, und dann eine Methode summarize definieren, die eine Standard-Implementierung hat und die Methode summarize_author aufruft:

#![allow(unused)]
fn main() {
pub trait Summary {
    fn summarize_author(&self) -> String;

    fn summarize(&self) -> String {
        format!("(Lies mehr von {}...)", self.summarize_author())
    }
}
}

Um diese Version von Summary zu verwenden, müssen wir summarize_author nur dann definieren, wenn wir das Merkmal für einen Typ implementieren:

#![allow(unused)]
fn main() {
pub trait Summary {
    fn summarize_author(&self) -> String;

    fn summarize(&self) -> String {
        format!("(Lies mehr von {}...)", self.summarize_author())
    }
}

pub struct Tweet {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub retweet: bool,
}

impl Summary for Tweet {
    fn summarize_author(&self) -> String {
        format!("@{}", self.username)
    }
}
}

Nachdem wir summarize_author definiert haben, können wir summarize auf Instanzen der Tweet-Struktur aufrufen, und die Standard-Implementierung von summarize wird die Definition von summarize_author aufrufen, die wir bereitgestellt haben. Da wir summarize_author implementiert haben, hat uns das Merkmal Summary das Verhalten der summarize-Methode mitgeliefert, ohne dass wir weiteren Code schreiben müssen.

use aggregator::{self, Summary, Tweet};

fn main() {
    let tweet = Tweet {
        username: String::from("horse_ebooks"),
        content: String::from("natürlich, wie du wahrscheinlich schon weißt"),
        reply: false,
        retweet: false,
    };

    println!("1 neue Kurznachricht: {}", tweet.summarize());
}

Dieser Code gibt 1 neue Kurznachricht: (Lies mehr von @horse_ebooks...) aus.

Beachte, dass es nicht möglich ist, die Standardimplementierung von einer übergeordneten Implementierung derselben Methode aus aufzurufen.

Merkmale als Parameter

Da du jetzt weißt, wie man Merkmale definiert und implementiert, können wir untersuchen, wie man Merkmale zur Definition von Funktionen verwendet, die viele verschiedene Typen akzeptieren. Wir verwenden das Merkmal Summary, das wir für die Typen NewsArticle und Tweet in Codeblock 10-13 implementiert haben, um eine Funktion notify zu definieren, die die Methode summarize für ihren Parameter item aufruft, der von einem Typ ist, der das Merkmal Summary implementiert. Um dies zu tun, können wir die Syntax impl Trait verwenden, etwa so:

#![allow(unused)]
fn main() {
pub trait Summary {
    fn summarize(&self) -> String;
}

pub fn notify(item: &impl Summary) {
    println!("Eilmeldung! {}", item.summarize());
}
}

Anstelle eines konkreten Typs für den Parameter item geben wir das Schlüsselwort impl und den Merkmalsnamen an. Dieser Parameter akzeptiert jeden Typ, der das angegebene Merkmal implementiert. Im Rumpf von notify können wir alle Methoden von item aufrufen, die vom Merkmal Summary herrühren, zum Beispiel summarize. Wir können notify aufrufen und jede Instanz von NewsArticle und Tweet angeben. Code, der die Funktion mit einem anderen Typ aufruft, z.B. String oder i32, lässt sich nicht kompilieren, da diese Typen kein Summary implementieren.

Merkmalsabgrenzungs-Syntax

Die Syntax impl Trait funktioniert für einfache Fälle, ist aber eigentlich syntaktischer Zucker für eine längere Form, die Merkmalsabgrenzung (trait bound) genannt wird; sie sieht so aus:

#![allow(unused)]
fn main() {
pub trait Summary {
    fn summarize(&self) -> String;
}

pub fn notify<T: Summary>(item: &T) {
    println!("Eilmeldung! {}", item.summarize());
}
}

Diese längere Form entspricht dem Beispiel im vorigen Abschnitt, ist aber wortreicher. Wir platzieren Merkmalsabgrenzungen in der Deklaration des generischen Typparameters nach einem Doppelpunkt und innerhalb spitzer Klammern.

Die Syntax impl Trait ist bequem und ermöglicht in einfachen Fällen einen prägnanteren Code, während die umfassendere Merkmalsabgrenzungs-Syntax mehr Komplexität ausdrücken kann. Zum Beispiel können wir zwei Parameter haben, die Summary implementieren. Das Verwenden der Syntax impl Trait sieht folgendermaßen aus:

pub fn notify(item1: &impl Summary, item2: &impl Summary) {

Die Verwendung von impl Trait ist angemessen, wenn wir wollten, dass diese Funktion bei item1 und item2 unterschiedliche Typen haben kann (solange beide Typen Summary implementieren). Wenn beide Parameter aber den gleichen Typ haben sollen, müssen wir eine Merkmalsabgrenzung verwenden, so wie hier:

pub fn notify<T: Summary>(item1: &T, item2: &T) {

Der als Parametertyp für item1 und item2 angegebene generische Typ T schränkt die Funktion so ein, dass der konkrete Typ der als Argument für item1 und item2 übergebenen Werte derselbe sein muss.

Angeben mehrerer Merkmalsabgrenzungen mit der Syntax +

Wir können auch mehr als eine Merkmalsabgrenzung angeben. Nehmen wir an, wir wollen, dass sowohl notify als auch die Methode summarize die Bildschirmausgabe für item formatieren: Spezifizieren wir in der notify-Definition, dass item sowohl Display als auch Summary implementieren muss. Wir können dies mit der Syntax + tun:

pub fn notify(item: &(impl Summary + Display)) {

Die Syntax + ist auch bei Merkmalsabgrenzungen mit generischen Typen gültig:

pub fn notify<T: Summary + Display>(item: &T) {

Mit den beiden angegebenen Merkmalsabgrenzungen kann der Rumpf von notify die Methode summarize aufrufen und {} verwenden, um item zu formatieren.

Klarere Merkmalsabgrenzungen mit where-Klauseln

Zu viele Merkmalsabgrenzungen zu verwenden, hat seine Schattenseiten. Jeder generische Datentyp hat seine eigenen Merkmalsabgrenzungen, sodass Funktionen mit mehreren generischen Typparametern viele Merkmalsabgrenzungsangaben zwischen Funktionsname und Parameterliste enthalten können, wodurch die Funktionssignatur schwer lesbar wird. Aus diesem Grund hat Rust für die Angabe von Merkmalsabgrenzungen eine alternative Syntax in Form einer where-Klausel nach der Funktionssignatur. Anstatt das hier zu schreiben:

fn some_function<T: Display + Clone, U: Clone + Debug>(t: &T, u: &U) -> i32 {

können wir eine where-Klausel wie folgt verwenden:

fn some_function<T, U>(t: &T, u: &U) -> i32
where
    T: Display + Clone,
    U: Clone + Debug,
{

Die Signatur dieser Funktion ist übersichtlicher: Der Funktionsname, die Parameterliste und der Rückgabetyp liegen nahe beieinander, ähnlich wie bei einer Funktion ohne viele Merkmalsabgrenzungen.

Rückgabetypen, die Merkmale implementieren

Wir können die Syntax impl Trait auch für den Rückgabetyp verwenden, wie hier gezeigt:

#![allow(unused)]
fn main() {
pub trait Summary {
    fn summarize(&self) -> String;
}

pub struct Tweet {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub retweet: bool,
}

impl Summary for Tweet {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}

fn returns_summarizable() -> impl Summary {
    Tweet {
        username: String::from("horse_ebooks"),
        content: String::from("natürlich, wie du wahrscheinlich schon weißt"),
        reply: false,
        retweet: false,
    }
}
}

Durch Verwenden von impl Summary für den Rückgabetyp legen wir fest, dass die Funktion returns_summarizable einen Typ zurückgibt, der das Merkmal Summary implementiert, ohne den konkreten Typ zu nennen. In diesem Fall gibt returns_summarizable einen Tweet zurück, aber der Code, der diese Funktion aufruft, muss das nicht wissen.

Die Fähigkeit, einen Rückgabetyp nur durch das Merkmal, das er implementiert, zu spezifizieren, ist besonders nützlich im Zusammenhang mit Funktionsabschlüssen und Iteratoren, die wir in Kapitel 13 behandeln. Funktionsabschlüsse und Iteratoren erzeugen Typen, die nur der Compiler kennt oder deren Spezifikation sehr lang ist. Mit der Syntax impl Trait kannst du prägnant angeben, dass eine Funktion einen Typ zurückgibt, der das Merkmal Iterator implementiert, ohne dass du einen sehr langen Typ schreiben musst.

Du kannst impl Trait jedoch nur verwenden, wenn du einen einzigen Typ zurückgibst. Beispielsweise würde dieser Code, der entweder einen NewsArticle oder einen Tweet mit dem Rückgabetyp impl Summary zurückgibt, nicht funktionieren:

#![allow(unused)]
fn main() {
pub trait Summary {
    fn summarize(&self) -> String;
}

pub struct NewsArticle {
    pub headline: String,
    pub location: String,
    pub author: String,
    pub content: String,
}

impl Summary for NewsArticle {
    fn summarize(&self) -> String {
        format!("{}, von {} ({})", self.headline, self.author, self.location)
    }
}

pub struct Tweet {
    pub username: String,
    pub content: String,
    pub reply: bool,
    pub retweet: bool,
}

impl Summary for Tweet {
    fn summarize(&self) -> String {
        format!("{}: {}", self.username, self.content)
    }
}

fn returns_summarizable(switch: bool) -> impl Summary {
    if switch {
        NewsArticle {
            headline: String::from(
                "Penguins gewinnen die Stanley-Cup-Meisterschaft!",
            ),
            location: String::from("Pittsburgh, PA, USA"),
            author: String::from("Iceburgh"),
            content: String::from(
                "Die Pittsburgh Penguins sind erneut die beste \
                 Eishockeymannschaft in der NHL.",
            ),
        }
    } else {
        Tweet {
            username: String::from("horse_ebooks"),
            content: String::from(
                "natürlich, wie du wahrscheinlich schon weißt",
            ),
            reply: false,
            retweet: false,
        }
    }
}
}

Die Rückgabe entweder eines NewsArticle oder eines Tweet ist aufgrund von Einschränkungen hinsichtlich der Implementierung der Syntax impl Trait im Compiler nicht erlaubt. Wie man eine Funktion mit diesem Verhalten schreibt, wird im Abschnitt „Merkmalsobjekte (trait objects) die Werte unterschiedlicher Typen erlauben“ in Kapitel 17 behandelt.

Verwenden von Merkmalsabgrenzungen zur bedingten Implementierung von Methoden

Durch Verwenden einer Merkmalsabgrenzung mit einem impl-Block, der generische Typparameter verwendet, können wir Methoden bedingt für Typen implementieren, die das angegebene Merkmal implementieren. Beispielsweise implementiert der Typ Pair<T> in Codeblock 10-15 immer die Funktion new, um eine neue Instanz von Pair<T> zurückzugeben (erinnere dich an den Abschnitt „Definieren von Methoden“ in Kapitel 5, dass Self ein Typ-Alias für den Typ des impl-Blocks ist, der in diesem Fall Pair<T> ist). Aber im nächsten impl-Block implementiert Pair<T> die Methode cmp_display nur, wenn ihr innerer Typ T die Merkmale PartialOrd und Display implementiert, die den Vergleich bzw. eine Ausgabe ermöglichen.

Dateiname: src/lib.rs

#![allow(unused)]
fn main() {
use std::fmt::Display;

struct Pair<T> {
    x: T,
    y: T,
}

impl<T> Pair<T> {
    fn new(x: T, y: T) -> Self {
        Self { x, y }
    }
}

impl<T: Display + PartialOrd> Pair<T> {
    fn cmp_display(&self) {
        if self.x >= self.y {
            println!("Das größte Element ist x = {}", self.x);
        } else {
            println!("Das größte Element ist y = {}", self.y);
        }
    }
}
}

Codeblock 10-15: Bedingte Implementierung von Methoden für einen generischen Typ in Abhängigkeit von Merkmalsabgrenzungen

Wir können auch ein Merkmal für beliebige Typen bedingt implementieren, die ein anderes Merkmal implementieren. Implementierungen eines Merkmals für Typen, die Merkmalsabgrenzungen erfüllen, werden als Pauschal-Implementierungen (blanket implementations) bezeichnet und kommen in der Rust-Standardbibliothek ausgiebig zur Anwendung. Beispielsweise implementiert die Standardbibliothek das Merkmal ToString für jeden Typ, der das Merkmal Display implementiert. Der impl-Block in der Standardbibliothek sieht in etwa so aus:

impl<T: Display> ToString for T {
    // --abschneiden--
}

Da die Standardbibliothek diese Pauschal-Implementierungen hat, können wir die to_string-Methode, die durch das Merkmal ToString definiert ist, bei jedem Typ aufrufen, der das Merkmal Display implementiert. Zum Beispiel können wir ganze Zahlen in ihre entsprechenden String-Werte umwandeln, weil ganze Zahlen Display implementieren:

#![allow(unused)]
fn main() {
let s = 3.to_string();
}

Pauschal-Implementierungen erscheinen in der Dokumentation des Merkmals im Abschnitt „Implementierer“ (implementors).

Mithilfe von Merkmalen und Merkmalsabgrenzungen können wir Code schreiben, der generische Typparameter verwendet, um Duplikationen zu reduzieren, aber auch dem Compiler gegenüber angeben, dass der generische Typ ein bestimmtes Verhalten haben soll. Der Compiler kann dann die Merkmalsabgrenzungen verwenden, um zu überprüfen, ob alle konkreten Typen, die von unserem Code verwendet werden, das richtige Verhalten aufweisen. In dynamisch typisierten Sprachen würden wir einen Laufzeitfehler erhalten, wenn wir eine Methode bei einem Typ aufrufen, der die Methode nicht definiert hat. Rust verschiebt diese Fehler jedoch in die Kompilierzeit und verlangt damit, dass wir die Probleme beheben, bevor unser Code überhaupt lauffähig ist. Außerdem müssen wir keinen Code schreiben, der das Verhalten zur Laufzeit überprüft, da wir es bereits zur Kompilierzeit überprüft haben. Auf diese Weise wird die Performanz verbessert, ohne die Flexibilität der generischen Datentypen aufgeben zu müssen.

Referenzen validieren mit Lebensdauern

Lebensdauer (lifetimes) sind eine weitere generische Funktionalität, die wir bereits verwendet haben. Anstatt sicherzustellen, dass ein Typ das von uns gewünschte Verhalten hat, stellen wir durch die Lebensdauer sicher, dass Referenzen so lange gültig sind, wie wir sie brauchen.

Ein Detail, das wir im Abschnitt „Referenzen und Ausleihen (borrowing)“ in Kapitel 4 nicht erörtert haben, ist, dass jede Referenz in Rust eine Lebensdauer (lifetime) hat, d.h. einen Gültigkeitsbereich, in dem diese Referenz gültig ist. In den meisten Fällen sind Lebensdauern implizit und abgeleitet, ebenso wie in den meisten Fällen Typen abgeleitet werden. Wir müssen Typen mit Annotationen versehen, wenn mehrere Typen möglich sind. In ähnlicher Weise müssen wir Lebensdauern annotieren, wenn die Lebensdauern von Referenzen auf verschiedene Weise miteinander in Beziehung gesetzt werden könnten. Rust verlangt von uns, die Beziehungen mit generischen Lebensdauerparametern zu annotieren, um sicherzustellen, dass die tatsächlich zur Laufzeit verwendeten Referenzen definitiv gültig sind.

Das Vermerken von Lebensdauern ist ein Konzept, das die meisten anderen Programmiersprachen nicht kennen, sodass es sich ungewohnt anfühlen wird. Auch wenn wir in diesem Kapitel die Lebensdauern nicht in ihrer Gesamtheit behandeln werden, so werden wir doch allgemeine Möglichkeiten erörtern, mit denen du dich mit der Syntax der Lebensdauer und den Konzepten vertraut machen kannst.

Verhindern hängender Referenzen mit Lebensdauern

Das Hauptziel der Lebensdauer ist es, hängende Referenzen (dangling references) zu verhindern, die dazu führen, dass ein Programm auf andere Daten referenziert als die, auf die es referenzieren soll. Betrachte das Programm in Codeblock 10-16, das einen äußeren und einen inneren Gültigkeitsbereich hat.

fn main() {
    let r;

    {
        let x = 5;
        r = &x;
    }

    println!("r: {}", r);
}

Codeblock 10-16: Ein Versuch, eine Referenz zu verwenden, deren Wert außerhalb des Gültigkeitsbereichs liegt

Hinweis: Die Beispiele in den Codeblöcken 10-16, 10-17 und 10-23 deklarieren Variablen ohne Initialwert, sodass der Variablenname im äußeren Gültigkeitsbereich existiert. Auf den ersten Blick mag dies im Widerspruch dazu stehen, dass Rust keine Nullwerte hat. Wenn wir jedoch versuchen, eine Variable zu verwenden, bevor wir ihr einen Wert geben, erhalten wir einen Kompilierfehler, der zeigt, dass Rust tatsächlich keine Nullwerte zulässt.

Der äußere Gültigkeitsbereich deklariert eine Variable r ohne Initialwert und der innere Gültigkeitsbereich deklariert eine Variable x mit dem Initialwert 5. Im inneren Gültigkeitsbereich versuchen wir, den Wert von r als Referenz auf x zu setzen. Dann endet der innere Gültigkeitsbereich und wir versuchen, den Wert in r auszugeben. Dieser Code lässt sich nicht kompilieren, weil der Wert, auf den sich r bezieht, den Gültigkeitsbereich verlassen hat, bevor wir versuchen, ihn zu verwenden. Hier ist die Fehlermeldung: