Type Conversions vs. Type Assertions

Der zentrale Unterschied

Die beiden Mechanismen lösen unterschiedliche Probleme und greifen zu unterschiedlichen Zeitpunkten:

Merksatz: Conversion ändert den Typ eines Werts. Assertion fragt nach dem Typ, der bereits in einem Interface steckt.

Type Conversion: T(v)

Die Syntax ist trivial — ein Typname, gefolgt vom Wert in Klammern:

var i int = 42
var f float64 = float64(i)   // int → float64
var u uint = uint(f)         // float64 → uint (Trunkierung)

b := []byte("hallo")         // string → []byte
s := string(b)               // []byte → string

Erlaubt ist eine Conversion grob dann, wenn Quell- und Zieltyp denselben Underlying Type haben oder explizit als kompatibel definiert sind (numerisch ↔ numerisch, string ↔ []byte/[]rune etc.). Die Go-Spec listet die exakten Regeln.

Was nicht geht, scheitert hart beim Compilieren — nicht erst zur Laufzeit:

var s string = "5"
var i int = int(s)   // ❌ cannot convert s (string) to int

Für Strings → Zahlen brauchst du strconv.Atoi, nicht int(...).

Numerische Konvertierungen

Zwischen allen numerischen Typen sind Conversions explizit erlaubt — aber nie implizit. Das ist eine bewusste Designentscheidung von Go:

var i int = 3
var f float64 = 3.9

a := float64(i)   // 3 (Wert ist float64, fmt zeigt aber „3“, nicht „3.0“)
b := int(f)       // 3   — Trunkierung Richtung Null!
c := int32(i)     // 3
d := byte(65)     // 65 (byte = uint8, Bereich 0–255)
e := rune(0x4E2D) // 中 (rune = int32, Codepoint)

// Achtung: Überlauf bei zu kleinem Zieltyp
var big int = 300
var sm int8 = int8(big)   // -56 (300 - 256 mod-Verhalten)

// %c druckt e als Zeichen; mit %v käme der Codepoint 20013
fmt.Printf("a=%v b=%v c=%v d=%v e=%c sm=%v\n", a, b, c, d, e, sm)

a=3 b=3 c=3 d=65 e=中 sm=-56

byte und rune sind nur Alias-Namen für uint8 bzw. int32. Sie tauchen oft in String-Verarbeitung auf.

String-Konvertierungen

Strings haben in Go besondere Conversion-Regeln, die einen typischen Anfänger-Stolperstein bilden:

s1 := string(65)              // "A"  — Codepoint, NICHT "65"!
s2 := string('世')            // "世" — rune-Literal
s3 := string([]byte{72, 105}) // "Hi"
s4 := string([]rune{0x4E2D})  // "中"

b := []byte("hallo")          // [104 97 108 108 111]
r := []rune("hé")             // [104 233]   2 Runen, nicht 3 Bytes

fmt.Printf("s1=%s s2=%s s3=%s s4=%s\n", s1, s2, s3, s4)
fmt.Printf("b=%v\n", b)
fmt.Printf("r=%v\n", r)

s1=A s2=世 s3=Hi s4=中
b=[104 97 108 108 111]
r=[104 233]

Memory-Hinweis: []byte(s) und string(b) kopieren in der Regel den Speicher — Strings sind in Go unveränderlich, Slices nicht. Für Hot-Loops mit großen Strings lohnt sich gelegentlich unsafe-Tricks oder strings.Builder, aber das ist eine spätere Optimierung.

Die Go-Spec listet alle vier String-Spezialfälle vollständig auf.

Type Assertion: x.(T)

Um die Type Assertion zu verstehen, musst du zuerst wissen, was ein Interface-Wert in Go wirklich ist. Ein Wert vom Typ any (oder error, oder jedem anderen Interface) ist nicht einfach der Wert selbst. Er ist ein Paar aus zwei Teilen: dem dynamischen Typ — also der Information, welcher konkrete Typ gerade darin steckt — und dem eigentlichen Wert. Sobald du etwas in ein Interface legst, klebt Go ein „Typ-Etikett“ daran und verbirgt den konkreten Typ hinter der Interface-Fassade. Ab da kannst du mit der Variable nur noch das tun, was das Interface selbst erlaubt — bei any also praktisch nichts außer es weiterzureichen.

Die Type Assertion x.(T) ist der Weg zurück: Sie nimmt den Interface-Wert und fragt „steckt hier konkret ein T drin?“. Passt das Etikett, bekommst du den ausgepackten Wert vom Typ T heraus und kannst wieder uneingeschränkt damit arbeiten.

var x any = "hallo"

         x  (Interface-Wert)
    +----------------------------+
    | dynamischer Typ : string   |  <- das Etikett
    | Wert            : "hallo"   |  <- die eigentlichen Daten
    +----------------------------+

    x.(string)   Etikett == string?  ja   -> "hallo"   (ok = true)
    x.(int)      Etikett == int?      nein -> 0, false  (ohne comma-ok: Panic)

Abgrenzung zur Conversion

Genau hier liegt der Unterschied zur Conversion aus den oberen Abschnitten — und diese Verwechslung ist der häufigste Stolperstein:

• Eine Conversion T(x) erzeugt einen neuen Wert eines anderen Typs und wird vom Compiler geprüft. float64(i) rechnet den int in einen float64 um — das Ergebnis ist ein anderer Speicherinhalt.
• Eine Assertion x.(T) erzeugt nichts Neues. Sie holt den bereits vorhandenen Wert unverändert aus dem Interface heraus und wird erst zur Laufzeit geprüft. Schlägt die Prüfung fehl, merkt der Compiler nichts davon; das Programm panickt erst beim Ausführen (oder liefert ok = false).

Merksatz: Conversion rechnet um, Assertion packt aus. Eine Conversion fragst du den Compiler, eine Assertion fragt die Laufzeit.

Die zwei Formen

var x any = "hallo"

// x trägt intern: dynamischer Typ = string, Wert = "hallo"

// Form 1: ohne comma-ok — packt aus, panickt bei Typ-Mismatch
s := x.(string)
fmt.Println(s)        // hallo

// Form 2: comma-ok bei Treffer — v hält den Wert, ok ist true
v, ok := x.(string)
fmt.Println(v, ok)    // hallo true

// Form 3: comma-ok bei Fehlschlag — KEIN Panic
n, ok := x.(int)      // x steckt ein string, kein int
fmt.Println(n, ok)    // 0 false   (0 = Nullwert von int)

hallo
hallo true
0 false

Was bei einem Fehlschlag passiert, hängt allein an der Form, die du wählst:

• Ohne comma-ok (s := x.(T)): Stimmt der Typ nicht, bricht das Programm sofort mit einem Panic ab — panic: interface conversion: interface {} is string, not int. Das willst du nur, wenn ein Mismatch ein echter Programmierfehler wäre.
• Mit comma-ok (v, ok := x.(T)): Du bekommst nie einen Panic. Bei einem Treffer ist ok true und v hält den ausgepackten Wert. Bei einem Fehlschlag ist ok false und v der Nullwert des Zieltyps — für int also 0, für einen Pointer nil. Genau das erklärt die Ausgabe 0 false: Der String steckt nicht als int drin, also liefert Go Nullwert plus false statt eines Absturzes.

Assertion gegen ein Interface

T muss kein konkreter Typ sein. Du kannst auch gegen ein anderes Interface asserten und damit fragen „erfüllt der verpackte Typ dieses Interface?“ — du prüfst dann nicht auf einen exakten Typ, sondern auf eine Fähigkeit (eine Methodenmenge):

var x any = someValue

// Hat der verpackte Typ eine String()-Methode?
if s, ok := x.(fmt.Stringer); ok {
    fmt.Println(s.String())   // ja — als Stringer behandelbar
}

So findet idiomatischer Go-Code heraus, ob ein beliebiger Wert sich etwa selbst als String darstellen kann, ganz ohne seinen konkreten Typ zu kennen.

Die kritische Voraussetzung gilt für alle Formen: x muss ein Interface-Typ sein (any, error, oder ein eigenes Interface). Auf einen konkreten Typ (int, string, *User) lässt sich x.(T) nicht anwenden — der Compiler blockiert das sofort, denn ein konkreter Typ trägt kein „Etikett“, das man abfragen könnte.

Comma-ok als sicherer Default

In Produktionscode ist die comma-ok-Form fast immer die richtige Wahl. Sie verhindert Panics und macht den Fehlerpfad explizit:

func describe(v any) string {
    if s, ok := v.(string); ok {
        return "string: " + s
    }
    if n, ok := v.(int); ok {
        return fmt.Sprintf("int: %d", n)
    }
    return "unbekannt"
}

Faustregel: Die Variante ohne ok benutzt du nur dann, wenn ein Mismatch ein Programmierfehler wäre — etwa direkt nach einem Type Switch, der die möglichen Typen schon abgrenzt.

Type Switch

Wenn mehrere Typen möglich sind, ist switch v := x.(type) lesbarer als eine Kette von Assertions:

func describe(v any) string {
    switch x := v.(type) {
    case nil:
        return "nil"
    case string:
        return "string der Länge " + strconv.Itoa(len(x))
    case int, int32, int64:
        return fmt.Sprintf("ein Integer: %v", x)
    case fmt.Stringer:
        return "Stringer: " + x.String()
    default:
        return fmt.Sprintf("unbekannt: %T", x)
    }
}

// describe("hi")     → string der Länge 2
// describe(42)       → ein Integer: 42
// describe(nil)      → nil

Achtung beim Mehrfach-Case wie case int, int32, int64: Innerhalb dieses Case hat x noch den ursprünglichen Interface-Typ — nicht den konkreten. Erst bei einem einzelnen Typ pro Case ist x automatisch eingegrenzt.

Wann KEINE Conversion möglich ist

Conversions setzen voraus, dass die Underlying Types passen. Defined Types schaffen hier reichlich Stolperfallen:

type Celsius float64
type Fahrenheit float64

var c Celsius = 21.0
var f Fahrenheit

f = c                     // ❌ Compile-Error: cannot use c as Fahrenheit
f = Fahrenheit(c)         // ✅ explizite Conversion ist OK,
                          //    Underlying Type ist beide Mal float64

var raw float64 = c       // ❌ ebenfalls Compile-Error
raw = float64(c)          // ✅ explizit konvertiert

Auch nicht möglich: Conversions zwischen Pointer-Typen mit unterschiedlichem Element-Typ. *int zu *int32 lässt sich nicht einfach via (*int32)(p) erzwingen — das geht nur über das unsafe-Paket und ist meistens ein Designsignal, etwas anders zu lösen.

Praxis: error → MyError mit errors.As

Ein häufiger Anwendungsfall in Go-Code: Du bekommst ein error-Interface zurück und willst prüfen, ob es ein bestimmter konkreter Typ ist. Hier könntest du theoretisch eine Type Assertion machen — idiomatisch ist aber errors.As:

type PathError struct {
    Op, Path string
    Err      error
}
func (e *PathError) Error() string { /* ... */ return e.Op }

// Type Assertion — funktioniert nur bei direktem Match
if pe, ok := err.(*PathError); ok {
    log.Printf("Pfadfehler bei %s", pe.Path)
}

// errors.As — durchläuft die Wrap-Chain (Empfehlung)
var pe *PathError
if errors.As(err, &pe) {
    log.Printf("Pfadfehler bei %s", pe.Path)
}

errors.As ist intern keine reine Type Assertion: es entpackt Unwrap()-Ketten und sucht den passenden Typ darin. Bei Errors, die mit fmt.Errorf("...: %w", inner) umhüllt wurden, findet eine schlichte Assertion den inneren Typ nicht — errors.As schon.

Weiterführende Ressourcen

Externe Quellen

• Conversions – Go Specification
• Type assertions – Go Specification
• Type switches – Go Specification
• errors.As – pkg.go.dev

Verwandte Artikel

• Interfaces – Type Assertion in Tiefe
• Int – Conversion zwischen Integer-Typen
• Float – Trunkierung bei Conversion
• String – Conversion-Spezialfälle
• Kontrollstrukturen – Type Switch