A golang proposal

No language is perfect. Every language has warts that can’t be designed away. Recently I’ve been noticing this pattern show up a lot:

thing, err := methodCouldErr()
if err != nil {
    return err
}

useThing(thing)

Error propagation in golang is done by returning error objects through the call stack until it’s ultimately consumed by some terminal caller. Done enough times – and I’ve seen entire functions comprised of successive uses of this idiom – this uses a lot of vertical real estate without adding much information. One way to avoid the vertical pollution is by combining the method call with the conditional:

if _, err := methodCouldErr(); err != nil {
    return err
}

This has an obvious drawback. A variable assigned inside the conditional can’t be used unless declared previously:

var thing Thing
var err error
if thing, err = methodCouldErr(); err != nil {
    return err
}

useThing(thing)

In the end, there are three different ways of propagating an error depending on what the situation needs, but it’s easy to mix these patterns up – I’ve seen all three in the same function on occasion.

At the risk of making it harder to decide, I propose a fourth pattern, a pattern to rule them all:

return if thing, err := methodCouldErr(); err != nil; err

useThing(thing)

I call this the return-if construct. It follows the syntax:

return if [statement; statement; ...]; conditional; return-value

Anything allowed in a normal if conditional is allowed here. The only difference is that there is one additional clause at the very end, the return-value. Variables declared in any of the statements would be in the calling scope, not the conditional scope, unlike an if conditional. This isn’t for a particular reason other than quality of life.

Since this is a language change, it clearly would cause compatibility issues. Additionally, it’s hard to know if this could ultimately decrease readability in the long run. There is value in conciseness and expressiveness, but horizontal complexity could produce a cognitive burden if done excessively.

I’m not sure if there’s a right answer in this situation but it would be interesting to see if this might be a net positive for the language. No language is perfect, and we should constantly think about ways of improving our tools as an industry.