Unit is the worst naming

Language Design
12

No, they return a very concrete “something”, but this something is usually ignored, because there is only one value for this type, and this value holds no data. So, you can think of it as: “This method returns something, but the result is so boring that you can safely ignore it.”

So why bother? I can see at least two reasons:

  • “Something” is not “nothing”. If you had a method in Java that would never return (infinite loop or throwing always an exception), you would give this method the same return type void like a “normal” method. In Kotlin you can do better, and distinguish it from normal methods by using Nothing instead of Unit. E.g. you have probably come across the TODO() function, and it only works because of this distinction.
  • Returning a rather boring, but regular value helps a lot when using generics. In Java you had all these special cases handling “no return value”, like the interface Consumer - in Kotlin it’s just a normal function returning Unit. Kotlin does more interesting stuff with generics, like more functional programming and extension methods, that makes it more important to avoid this quirk (similar as it is avoiding the problems Java has with primitive types as generic parameters)

Don’t think Unit is the same as void, it really isn’t. It is a very normal type with a single value (also named Unit) that helps to make the type system more regular. You can assign it to variables, it can be an argument, there is nothing special about it, except that you don’t have to return it explicitly in a function, and that it is exceptionally boring.

5 Likes