An interface value hides the concrete type inside it. A type assertion is how you ask, at runtime, "is the value in this interface actually a Product?", and pull it out as the concrete type if it is. This lesson covers the two forms of the assertion expression, the safe comma-ok idiom, how nil interfaces behave under assertions, and how to assert from one interface to another to detect optional capabilities.

The empty interface (any) presents a problem. A variable of type any can hold anything, but once it's in there, you can't do much with it. You can print it, compare it for equality in some cases, and pass it around, but the methods and fields of the underlying type are out of reach. The same is true for any interface: a Payable value lets you call Pay, but if the concrete value also has a RefundPolicy field or a Track method that isn't in the Payable interface, those are invisible through the interface variable.

The commented-out line shows the limit. Even though we know the underlying value is a string and strings work with len, the compiler only sees an any. To do anything string-specific, we have to recover the static type first. That recovery is what a type assertion performs.

A type assertion has the shape x.(T), where x is a value of some interface type and T is the type you're asserting it to. Go gives you two forms of this expression, and the choice between them is about how you want to handle the case where the assertion is wrong.

The one-value form returns the unboxed value or panics if the type doesn't match.

value.(string) says "I'm telling you this is a string, give me the string." Since the concrete type really is string, the expression produces "BOOK-01" of type string. From that point on, code is a regular string variable. You can call len(code), slice it, compare it, anything strings normally support.

The comma-ok form returns the unboxed value plus a boolean that reports whether the assertion held.

The comma-ok form is doing the same check, but instead of panicking on a mismatch it sets ok to false and gives back the zero value of T for the first result. Your code decides what to do next.

Both forms compile down to the same runtime check. The difference is purely in how a failed assertion is reported: as a panic, or as a false boolean.

The behavior splits cleanly between the two forms once the concrete type doesn't match what you asserted.

The runtime error tells you exactly what happened: the interface held an int, but the code asked for a string. The program aborts unless something recovers the panic. There's no defensive fallback, no zero value returned, just a crash.

Switching to the comma-ok form turns the same mismatch into a tidy false:

code comes back as "", the zero value of string, and ok is false. The program runs to completion. This is the form to prefer in any code where the input could legitimately be of a different type, which is almost all of them.

A type assertion is a runtime check (essentially a comparison against a type descriptor in the interface header), not a free operation. It's cheap enough for normal use in business logic, but tight loops doing millions of assertions per second can show it on a profile. Move the assertion out of the loop when you can, or sort the values by type first.

The one-value form looks shorter, but the comma-ok form is what most Go code uses. The reasoning is simple: a panicking assertion crashes the whole program for one bad input, and most programs handle many inputs. A panic in the middle of processing one customer's order is bad enough; a panic that takes down a request-handling server is much worse.

Use the one-value form only when both of these are true:

Everything else gets the comma-ok form. It's two extra characters and a boolean check, and it converts every potential panic into ordinary control flow.

The function takes an any and behaves sensibly for any input. The first call matches and prints the product name. The second and third don't match, so the early return handles them without a panic. This shape, assert into the comma-ok form and bail out on !ok, is the standard tool pattern.

A nil interface value behaves predictably under assertion, but the rules are subtle enough to state directly.

A nil interface has no dynamic type and no dynamic value. Any assertion against it fails.

The comma-ok form returns the zero value of the target type and ok = false, exactly as it would for a non-nil interface with the wrong dynamic type. The one-value form panics, with a slightly different message that says the interface was nil. Both behaviors fall out of the same rule: nil is not of any concrete type, so no concrete-type assertion can succeed.

This matters when you're writing functions that accept an interface and the caller might pass a zero value:

The comma-ok assertion handles the nil input gracefully: ok is false, so the function moves on to the explicit p == nil check and reports it. Without comma-ok, the very first line would panic on a nil input.

So far the target T has been a concrete type like string, int, or Product. Type assertions also let you target another interface, which is how Go does feature detection. You have a value of one interface type, and you want to know whether the underlying concrete type also satisfies a richer interface.

This shows up all over the standard library. The io package defines io.Writer as anything with a Write method, but some writers also have a WriteString method that's more efficient when writing strings (no []byte conversion needed). Code that wants the optimization assertion-checks for the richer interface.

Here's the same pattern in an e-commerce setting. A base Notifier interface says any notifier can send a message. Some notifiers also support priority, expressed by a separate PriorityNotifier interface. Code that has only a Notifier can ask, "does this concrete value happen to also be a PriorityNotifier?"

The notify function is parameterized on the smaller Notifier interface, so it works with anything that can send. When the caller flags a message as urgent, the function asks: "does this concrete value also satisfy PriorityNotifier?" If yes, it sets a priority level. If not, the assertion's ok is false and the function just sends the message as-is. Either path ends in a normal Send.

The EmailNotifier doesn't have a SetPriority method, so the assertion fails for it and the urgent flag is ignored. The *SMSNotifier does have one, so the assertion succeeds and SetPriority(10) runs before Send. The two notifier types don't know about each other, and neither one had to be modified to support priorities; the SMS type just opted in by having the right method.

This is what Go developers mean by "feature detection through interface assertion." Instead of forcing every implementer of Notifier to also implement SetPriority, you let each one opt in. Callers detect the capability at runtime and use it when it's there.

The same interface-to-interface pattern shows up in error handling. Many error types in the standard library provide extra information through optional interfaces. The net package, for example, returns errors that satisfy interface { Temporary() bool } when the error might go away if you retry. Calling code uses an interface assertion to detect this.

The target type in the assertion is an anonymous interface, written inline as interface{ Temporary() bool }. Go lets you do that; you don't have to declare a named interface just to assert against it. The comma-ok result lets the caller distinguish "this error type doesn't claim to be retryable" from "this error type says it isn't retryable right now" (the second case would be ok = true, temp.Temporary() == false).

The standard library has formalized this pattern through errors.As, which is the preferred way to dig out a specific error type or capability from a wrapped chain of errors. The error-handling section covers errors.As in depth. For now, the takeaway is that the underlying mechanism is a type assertion, and is manual versions in older Go code and in code that hasn't switched yet.

It helps to picture what's happening inside the interface value. An interface variable holds two pieces of information: a pointer to a type descriptor (which type the value actually is) and a pointer to the value itself. A type assertion x.(T) does roughly the following:

The diagram captures three cases. When the interface is nil, every assertion fails. When the target T is a concrete type, the runtime compares the dynamic type to T directly: they have to be the same type for the assertion to succeed. When T is itself an interface, the runtime instead checks whether the dynamic type's method set includes every method T requires. That second check is what makes n.(PriorityNotifier) work even though n holds a *SMSNotifier, not a PriorityNotifier value.

One implication: asserting from a wider interface to a narrower interface that the dynamic type happens to satisfy is cheap and common in Go code. You don't need to register an *SMSNotifier as a PriorityNotifier ahead of time. The runtime walks the methods at assertion time and decides.

Runtime method-set checks for interface-to-interface assertions involve walking the method table, but Go caches the result of recent checks, so repeated assertions of the same pair are fast in practice. Still cheaper than reflection by a wide margin.

A type assertion handles one target type per expression. Chaining several of them works, but it gets repetitive fast.

This works, but the visual noise is real: three near-identical blocks, three early returns, three ok boolean checks. Go has a dedicated construct for exactly this case, called a type switch, which compresses the same logic into a much cleaner form. The rule of thumb is straightforward: one or two target types, use comma-ok assertions; more than that, use a type switch.

Some assertion patterns come up so often that they're worth recognizing on sight.

Pulling a known concrete type out of a generic container.

The slice mixes types because it was declared as []any. The loop assertion-extracts only the strings and ignores everything else. This shows up in code that decodes JSON into map[string]any or interacts with a reflection-based library.

Detecting an optional capability on an existing interface value.

You have an io.Writer and want to close it if the concrete type also happens to be an io.Closer. The assertion gives you a yes/no answer at runtime. If yes, the cleanup happens; if no, the code carries on without it.

Unwrapping a specific error type.

The function returns an error, but the caller wants to know whether it's specifically a *RetryableError to decide how to react. The comma-ok form makes this safe even when the error is nil or of an unrelated type. In modern Go, errors.As is the preferred way to do this through a chain of wrapped errors; the chapter on error handling explains the difference.