Why Does Type Assertion Fail with Custom Types in Go?

Named Type Assertions and Conversions in Go

When defining custom types in Go, it's possible to redefine predefined types with a new name. However, when attempting to use these custom types in functions that expect the predefined type, errors may occur. Let's delve into the reasons behind these errors and explore solutions.

Consider the following code:

<code class="go">type Answer string

func acceptMe(str string) {
    fmt.Println(str)
}

func main() {
    var ans Answer = "hello"

    // Cannot use ans (type Answer) as type string in function argument
    acceptMe(ans)

    // Invalid type assertion: ans.(string) (non-interface type Answer on left)
    acceptMe(ans.(string))

    // Works, but why?
    acceptMe(string(ans))
}</code>

Why the Type Assertion Fails

Type assertions only work for interfaces. Interfaces can have any underlying type, allowing for type assertion or type switch. However, in this case, Answer is a custom type with a single underlying type, string. There's no need for type assertion since the conversion to the underlying type is guaranteed to succeed.

Why the Conversion Works

Conversions, on the other hand, can be performed between types that have a known relationship, as is the case with Answer and string. The syntax string(ans) explicitly converts the Answer type to the underlying string type.

Conclusion

It's important to understand the distinction between type assertions and conversions. Type assertions should be used with interfaces to check the underlying type dynamically. Conversions, on the other hand, are used to explicitly convert between types with known relationships. In the case of Answer and string, conversion is the recommended approach since it provides a predictable and clear way to interoperate with the underlying type.

The above is the detailed content of Why Does Type Assertion Fail with Custom Types in Go?. For more information, please follow other related articles on the PHP Chinese website!