Changing behavior based on number of return arguments like type assertions

I've been learning Go and one thing that stood out as particularly interesting to me is the way that the behavior of type assertions changes based on how many return values are being captured:

var i interface{} = "hello"

val, ok := i.(int) // All good
fmt.Println(val, ok)

val = i.(int) // Panics
fmt.Println(val)

This feels like a pattern that can be very useful for user defined functions. The user either has to explicitly get the "ok" second return value or use an underscore to ignore it. In either case, they're making it clear that they're aware that the function can fail. Whereas if they just get one return value, it could silently fail. Hence, it seems reasonable to panic or similar if the user isn't checking for an error (which would be reasonable if the error should "never" happen). I assume that's the logic behind the language developers in making type assertions work this way.

But when I tried to find out how that could be done, I found nothing. I'm aware that type assertions aren't an actual function. And many languages with multiple return values can't check how many return values are actually being used (MATLAB is the only one I'm aware of), but then again, most of those don't use behavior like the type assertions demonstrate.

So, is it possible and if so, how? If not, is there a particular reason that this behavior was excluded despite it being possible with the built in type assertions?

Sadly they cannot be used in normal functions. As far as i know only type assertions, map value access and range allow it.

Usually when you want to have a function with one and optional a second error argument you name them like

func DoSomething() (string, error) {...} // i will return an error
func MustDoSomething() string {...}  // i will panic

An example would be https://golang.org/pkg/regexp/#MustCompile

This answer: https://stackoverflow.com/a/41816171/10278 by @christian provides the best practical advice for how to emulate the "overloaded-on-result-count" pattern.

My aim is to address another part of the question—this part: "But when I tried to find out how that could be done, I found nothing".

The following explains how it is done for Go type assertions.

Invocations of type assertions in Go behave as though they are overloaded based on number of results.

Yet, Go does not support overloading of methods and operators.

Looking at Go's implementation, here is the reason type assertions appear to be overloaded based on number of results:

• The Go compiler provides special handling that is peculiar to these built-in operations.

This special dispatching occurs for the built-in concept of type assertions because the compiler is carving out special logic that is not available to non-built-in code.

The Go compiler and runtime are written in Go. That made it (somewhat) easy for me to discover that the compiler is the key to explaining this behavior.

Take a look at this part of the compiler:

• https://github.com/golang/go/blob/8d86ef2/src/cmd/compile/internal/gc/ssa.go#L4782

The code comment already reveals a lot:

// dottype generates SSA for a type assertion node.
// commaok indicates whether to panic or return a bool.
// If commaok is false, resok will be nil.

We can go further by using a debugger to step through some type assertion code.

Take this playground snippet for example. Specifically, these lines:

object_as_closer_hardstop     := thing.(io.Closer) // will panic!!
object_as_closer,      ok     := thing.(io.Closer)

(If you build Go from source, then) if you use a debugger to step into the first type assertion, you will end up at the following code in the Go runtime:

• https://github.com/golang/go/blob/8d86ef2/src/runtime/iface.go#L438

If you step into the second one, you end up at:

• https://github.com/golang/go/blob/8d86ef2/src/runtime/iface.go#L454

On line 438, you see func assertI2I (with a single return value). A bit lower, on line 454, you see assertI2I2. Note that these two functions have nearly identical names, but not quite!

The second function has a trailing 2 at the end of its name. That function also has two returned results.

As we expect:

• assertI2I can panic, but
• assertI2I2 cannot.

(Look at the function bodies in iface.go and note which contains panic.)

assertI2I and assertI2I2 abide by the overloading rules we expect. If they were to differ only by number of results, then those of us who compile Go from source would be unable to compile the Go runtime, due to a compiler error such as "assertI2I redeclared".

Users of the language are generally not aware of these builtin runtime functions, so on the surface, both lines of code seem to call the same function:

object_as_closer_hardstop     := thing.(io.Closer) // will panic!!
object_as_closer,      ok     := thing.(io.Closer)

However, at compile time the compiler branches based on whether it found the case "commaok":

• https://github.com/golang/go/blob/8d86ef2/src/cmd/compile/internal/gc/ssa.go#L4871

Our own end-user code does not get to modify Go's lexing/parsing/AST-walking in order to dispatch different flavors of our functions based on "commaok".

For better or for worse, that is why user-written code cannot leverage this pattern.