Go: cannot use x (variable of type T) as type U in assignment

The exact error string

package main

func main() {
    var x int = 10
    var y int64 = x
    _ = y
}

// ./main.go:5:15: cannot use x (variable of type int) as int64 value in assignment
//
// older Go toolchains (pre 1.18) phrased it as:
// ./main.go:5:15: cannot use x (type int) as type int64 in assignment

The tail changes with context but the shape stays the same: in assignment becomes in argument to f when it's a function call, and in return statement when a return doesn't match the declared return type. All three come from the same rule and take the same fix.

When the target is an interface rather than a concrete type, the message gets an extra line naming exactly what's missing:

// cannot use w (variable of type Writer) as type io.Writer value in argument to save:
//     Writer does not implement io.Writer (missing method Write)

Why Go makes you write the conversion

Most languages with numeric subtyping will quietly widen an int to a float64, or truncate an int64 into an int32, wherever the context demands it. Go's designers considered that a source of exactly the kind of bug that's expensive to find later: a silent truncation that only shows up when a value happens to exceed 32 bits in production. Go's answer is to require every conversion to be visible in the source as T(x) — nothing converts by accident, and a reviewer can see precisely where a narrowing or reinterpretation happens.

This is not the same rule as Rust's type mismatch (E0308), though the symptom looks similar: Rust infers types and then enforces exact matches after inference; Go has no inference for this case at all — assignment between differently-typed variables is categorically disallowed unless you convert.

Fix 1: numeric type mismatch

Go's numeric types — int, int8/16/32/64, uint variants, float32/64 — are all distinct types with no automatic promotion between them, even when one clearly fits inside the other. Convert explicitly:

var x int = 10
// ❌ var y int64 = x
var y int64 = int64(x)   // ✅ widening — always safe

var big int64 = 1 << 40
// ❌ var small int32 = big
var small int32 = int32(big)   // ✅ compiles, but TRUNCATES — 1<<40 doesn't fit in int32

var price float64 = 19.99
// ❌ var count int = price
var count int = int(price)   // ✅ compiles, but TRUNCATES toward zero: 19, not 20

Note the two comments above marked "compiles, but" — the compiler only enforces that the conversion is written, not that it's safe. Narrowing (int64→int32) can silently drop high bits, and float→int truncates toward zero rather than rounding. If the value might not fit, check the range yourself or use math.Round before converting.

Fix 2: string vs []byte

Strings and byte slices are different types in Go even though a string is backed by bytes. Functions that expect one won't accept the other without conversion:

func writeBytes(b []byte) { /* ... */ }

s := "hello"
// ❌ writeBytes(s)
writeBytes([]byte(s))   // ✅ allocates a new byte slice, copies s

var b []byte = []byte{'h', 'i'}
// ❌ var s2 string = b
var s2 string = string(b)   // ✅ allocates a new string, copies b

Both directions allocate and copy — there's no free reinterpretation, because a string is immutable and a []byte isn't, so sharing the underlying array would violate that guarantee. If you're converting in a hot loop, that copy is worth knowing about; strings.Builder or bytes.Buffer avoid it for incremental building.

Fix 3: two named types with the same underlying type

This is the case that surprises people coming from languages with structural typing. Two types declared with type are different types even if their underlying representation is identical — Go's identity rule is by declared name, not by shape:

type Celsius float64
type Fahrenheit float64

func toF(c Celsius) Fahrenheit {
    return Fahrenheit(c*9/5 + 32)   // ✅ explicit conversion required
}

func main() {
    var c Celsius = 100
    // ❌ var f Fahrenheit = c   — cannot use c (variable of type Celsius) as Fahrenheit value in assignment
    var f Fahrenheit = Fahrenheit(c)   // ✅
    _ = f
}

This is intentional, not a limitation: it stops you from accidentally treating a temperature in Celsius as one in Fahrenheit just because both happen to be stored as float64. One exception worth knowing: an untyped constant (a literal like 98.6, not a variable) converts implicitly to any compatible named type, so toF(98.6) compiles without a cast even though toF(someFloat64Variable) would not.

Fix 4: the tail says "does not implement" — an interface, not a conversion

When the target type is an interface, the fix is different from the three above — you can't cast your way to satisfying an interface. The message tells you exactly what's missing:

type Writer interface {
    Write(p []byte) (n int, err error)
}

type logger struct{}

func (l *logger) Write(p []byte) (int, error) { return len(p), nil }

func save(w Writer) { /* ... */ }

func main() {
    l := logger{}
    // ❌ save(l)
    // cannot use l (variable of type logger) as Writer value in argument to save:
    //     logger does not implement Writer (method Write has pointer receiver)
    save(&l)   // ✅ &l is *logger, which has Write in its method set
}

Two things to check when you see this tail. First, is the method genuinely missing, or is it a typo in the name or signature (wrong parameter types, wrong return count)? Second — the case above — is the method defined on a pointer receiver (func (l *logger) Write(...))? A value type's method set only includes value-receiver methods; you must pass a pointer (&l) to satisfy an interface that requires a pointer-receiver method. This is the single most common trigger for this variant of the error.

To catch a missing-implementation bug at compile time even before you call anything, a common idiom is a standalone assertion line: var _ Writer = (*logger)(nil) — it compiles to nothing at runtime but forces the compiler to check the interface is satisfied right where you declare the type.

Quick reference

Debugging checklist

• ✓ Read the message's tail — "in assignment" / "in argument to f" / "in return statement" tells you where
• ✓ Does it end "does not implement"? That's a missing interface method, not a type mismatch — go to Fix 4
• ✓ Numeric types? Convert with TargetType(x), and double-check narrowing doesn't lose data
• ✓ string/[]byte? Convert with []byte(s) or string(b)
• ✓ Two custom types with the same underlying representation? You still need an explicit conversion
• ✓ Interface target, "does not implement", naming a real method you wrote? Check for a pointer-receiver mismatch first
• ✓ Still stuck? Run go vet and hover the value in your editor (gopls) to confirm its exact inferred type