Implicit returns are a feature in some languages. They have recently bitten me, so here's my opinion. Statements, expressions, and returns Before diving into implicit returns, we must explain two programming concepts influencing them. A lot of literature is available on the subject, so I'll paraphrase one of the existing definitions: An expression usually refers to a piece of code that can be evaluated to a value. In most programming languages, there are typically three different types of expressions: arithmetic, character, and logical. A statement refers to a piece of code that executes a specific instruction or tells the computer to complete a task. -- Expression vs. Statement Here's a Kotlin snippet: val y = 10                //1
val x = 2                 //1

x + y                     //2

println(x)                //1 Statement, executes the assignment "task" Expression, evaluates to a value, , 12 e.g. Functions may or may not return a value. When they do, they use the keyword in most programming languages. It's a statement that needs an expression. return In Kotlin, it translates to the following: fun hello(who: String): String {
    return "Hello $who"
} In this regard, Kotlin is similar to other programming languages with C-like syntax. Implicit returns A couple of programming languages add the idea of returns: Kotlin, Rust, Scala, and Ruby are the ones I know about; each has different quirks. implicit I'm most familiar with Kotlin: you can omit the keyword when you switch the syntax from a to an . With the latter, you can rewrite the above code as the following: return block body expression body fun hello(who: String): String = "Hello $who" Rust also allows implicit returns with a slightly different syntax. fn hello(who: &str) -> String {
    return "Hello ".to_owned() + who;          //1
}

fn hello_implicit(who: &str) -> String {
    "Hello ".to_owned() + who                  //2
} Explicit return Transform the statement in expression by removing the trailing semicolon - implicit return Let's continue with Kotlin. The expression doesn't need to be a one-liner. You can use more complex expressions: fun hello(who: String?): String =
    if (who == null) "Hello world"
	else "Hello $who" The pitfall I was writing code lately, and I produced something akin to this snippet: enum class Constant {
    Foo, Bar, Baz
}


fun oops(constant: Constant): String = when (constant) {
    Constant.Foo -> "Foo"
    else -> {
        if (constant == Constant.Bar) "Bar"
        "Baz"
    }
} Can you spot the bug? Let's use the function to make it clear: fun main() {
	println(oops(Constant.Foo))
	println(oops(Constant.Bar))
	println(oops(Constant.Baz))
} The results are: Foo
Baz
Baz The explanation is relatively straightforward. does nothing. The following line evaluates to ; it implicitly returns the expression. To fix the bug, we need to add an to transform the block into an expression: if (constant == Constant.Bar) "Bar" "Bar" else if (constant == Constant.Bar) "Bar"
else "Baz" Note that for simpler expressions, the compiler is smart enough to abort with an error: fun oops(constant: Constant): String =
    if (constant == Constant.Bar) "Bar"      //1
    "Baz" 'if' must have both main and 'else' branches if used as an expression Conclusion Implicit return is a powerful syntactic sugar that allows for more concise code. However, concise code doesn't necessarily imply being better code. I firmly believe that explicit code is more maintainable in most situations. In this case, I was tricked by my code! Beware of implicit returns. Go further: Expression vs. Statement Rust, Ruby, and the Art of Implicit Returns To be clear, Rust does not have "implicit returns" On the merits of verbosity and the flaws of expressiveness Originally at on March 17th, 2024 published A Java Geek

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

The Pitfalls of Implicit Returns

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

16 Best Practices For Securing Your APIs with Apache APISIX - Part 1

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

10 Websites to Learn JavaScript for Beginners

16 Best Practices For Securing Your APIs with Apache APISIX - Part 1

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

10 Websites to Learn JavaScript for Beginners

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps