为何Go语言中必然失败的类型断言不会被视为语法错误？

Great question—this gets to the core of how Go's interfaces and type system differ from C++'s generics, and ties directly into Go's original design philosophy. Let's break this down:

First, Go's empty interface isn't generics #

Your initial confusion makes total sense, especially with Eduardo Thales' point that Go's generics were added later (in Go 1.18). The interface{} (empty interface) isn't a generic type—it's a mechanism to hold any value alongside its runtime type information. At compile time, the variable i has a static type of interface{}—the compiler has no way to track what concrete type is stored inside it at runtime. That's why it can't flag the mistake when you try to assert it to float64: as far as the compiler knows, i could hold a float64 later in the program.

Contrast with C++ generics #

C++'s generics rely on compile-time instantiation. When you write a generic function or class, the compiler generates a separate version of the code for each concrete type you use it with. So if you try to pass a string to a generic function expecting a float, the compiler immediately sees the mismatch and throws an error—there's no ambiguity at runtime because each type gets its own specialized code.

Go's design trade-off #

Go prioritizes simplicity, fast compilation, and flexible duck typing. The empty interface was a key part of Go's early approach to polymorphism, letting you write code that works with any type without explicit type hierarchies. Runtime type checks are the trade-off for that flexibility: you get the ability to handle arbitrary types, but you have to validate them at runtime (either with the comma-ok idiom f, ok := i.(float64) to avoid panics, or using type switches).

Now with Go generics (1.18+) #

Since generics were added, you can get compile-time type safety for many scenarios that previously required empty interfaces. For example, if you want a function that only works with floats, you could write:

func processFloat[T float64](val T) {
    // Do something with val
}

// This will fail at compile time, exactly like C++
processFloat("hello")

This gives you the best of both worlds: type safety at compile time, without giving up the flexibility Go is known for.

Wrap-up #

Go doesn't catch type assertion errors at compile time because empty interfaces are designed to be dynamically typed—their whole purpose is to let you work with values whose concrete types aren't known until runtime. If you want compile-time checks, use Go's modern generics instead. And always remember the comma-ok idiom when using type assertions to avoid unexpected panics!

内容的提问来源于stack exchange，提问作者Deepanshu Lulla