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.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)

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

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)

Die Type Assertion fragt einen Interface-Wert, ob der darin verpackte konkrete Typ T ist:

var x any = "hallo"

// Variante 1: ohne comma-ok — panischt bei Mismatch
s := x.(string)
fmt.Println(s)   // hallo

// Variante 2: mit comma-ok — sicher
n, ok := x.(int)
fmt.Println(n, ok)   // 0 false

hallo
0 false

Die kritische Voraussetzung: 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.

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