Why Does Type Assertion Fail with Custom Types in Go, But Conversion Succeeds?

Named Type Assertions and Conversions in Go

In Go, named type assertions and conversions allow developers to manipulate custom and predefined data types. However, misconceptions can arise when dealing with custom types that redefine predefined ones. Let's explore this issue in detail.

Consider the following code example:

<code class="go">type Answer string

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

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

    // Illegal usage
    acceptMe(ans)

    // Failed type assertion
    acceptMe(ans.(string))

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

Q: Why does the type assertion (ans.(string)) fail, while the conversion (string(ans)) works?

A: Type assertions are only applicable to interface types, which represent a contract that a value can fulfill. Since custom types like Answer are not interfaces, attempting to assert them using the type assertion syntax will result in an error.

In contrast, conversions explicitly transform one type to another. The conversion (string(ans)) succeeds because Answer has an underlying string type. Go implicitly converts Ans to its underlying string before passing it to acceptMe.

Additional Notes:

• Custom types like Answer are essentially aliases for existing types. They do not add new capabilities or behaviors.
• Type assertions provide runtime type checking, while conversions perform implicit type coercion.
• When dealing with custom types that wrap predefined types, it's generally recommended to use conversions instead of type assertions, as they are more efficient and always succeed if the underlying types match.

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