The Problem with Multiple Return Values

Multiple return values are still a pretty new concept. One might have heard of languages with said feature, like Go and Odin. The creator of Odin, gingerBill, has written an article about this topic. If you are not familiar with it, you should read it.

Some advantages come with multiple return values. Your code can be more compact. It enables you to write code faster. The code might even look cleaner.

But the current implementations don't come without problems. The biggest one is implicit types. Both Go and Odin can infer a variable type when initializing. While developing, this is great. Spending less time on writing types and more on shipping features. Awesome! But what about the others that have to read the code?

Let's look at a simple initialization in Go to illustrate what I mean.

year, month, day := time.Now().Date()

It's straightforward. We call time.Now().Date() and receive three separate values. We assign these values to year, month, and day. If you use your editor, you can see what the function returns. Outside of a development environment? You are out of luck.

Sure, it's a function out of Go's standard library. That means a Go developer might know what types the return values have. But what about self-written functions? You can give the variables a clear name, as I did, or declare them before calling the function.

Both approaches don't solve the problem. Looking at the code again, you might guess the types. The logical guess would be either integers or, which are less flexible, strings. The second guess would be 100% wrong. The first is at least 67% right. Let's drop the curtain and show the second approach to see the types.

var year int
var month time.Month
var day int
year, month, day = time.Now().Date()

Declaring the variables beforehand does help but doesn't solve the problem. It's not different in Odin.

Variable names can't include spaces. So, the following pseudocode might be a step in the right direction.

year int, month time.Month, day int := time.Now().Date()

It's not as pretty, but it would allow us to be explicit when declaring variables in such a manner.

Is this a reason to avoid multiple return values? No. Their advantages outweigh their disadvantages. Thanks to them, both languages can have errors as values. No try-catch-blocks. Odin also offers keywords that take advantage of multiple return values. They allow for simple and readable code at the price of explicit type declarations. A price that might be worth paying for.