在scala中显式提供方法返回类型或变量类型的好处

Question

This question may be very silly, but I am a little confused which is the best way to do in scala. In scala, compiler does the type inference and assign the most closest(or may be Restrictive) type for each variable or a method. I am new to scala, and from many sample code/ libraries, I have noticed that in many places people are not explicitly providing the types for most of the time. But, in most of the code I wrote, I was/still am explicitly providing the types. For eg:

val someVal: String = "def"

def getMeResult() : List[String]= {
  val list:List[String] = List("abc","def")
  list
}

The reason I started to write this especially for method return type is that, when I write a method itself, I know what it should return. So If I explicitly provide the return type, I can find out if I am making any mistakes. Also, I felt it is easier to understand what that method returns by reading the return type itself. Otherwise, I will have to check what the return type of the last statement.

So my questions/doubts are : 1. Does it take less compilation time since the compiler doesn't have to infer much? Or it doesn't matter much ? 2. What is the normal standard in the scala world?

Answer 1

From " Scala in Depth " chapter 4.5 :

For a human reading a nontrivial method implementation, infering the return type can be troubling. It's best to explicitly document and enforce return types in public APIs.

From " Programming in Scala " chapter 2 :

Sometimes the Scala compiler will require you to specify the result type of a function. If the function is recursive, for example, you must explicitly specify the function's result type.

It is often a good idea to indicate function result types explicitly. Such type annotations can make the code easier to read, because the reader need not study the function body to figure out the inferred result type.

From " Scala in Action " chapter 2.2.3 :

It's a good practice to specify the return type for the users of the library. If you think it's not clear from the function what its return type is, either try to improve the name or specify the return type.

From " Programming Scala " chapter 1 :

Recursive functions are one exception where the execution scope extends beyond the scope of the body, so the return type must be declared.

For simple functions perhaps it's not that important to show it explicitly. However, sometimes the inferred type won't be what's expected. Explicit return types provide useful documentation for the reader. I recommend adding return types, especially in public APIs.

You have to provide explicit return types in the following cases :

• When you explicitly call return in a method.
• When a method is recursive.
• When two or more methods are overloaded and one of them calls another; the calling method needs a return type annotation.
• When the inferred return type would be more general than you intended, eg, Any.

Answer 2

Another reason which has not yet been mentioned in the other answers is the following. You probably know that it is a good idea to program to an interface, not an implementation .

In the case of return values of functions or methods, that means that you don't want users of the function or method to know what specific implementation of some interface (or trait) the function returns - that's an implementation detail you want to hide.

If you write a method like this:

trait Example
class ExampleImpl1 extends Example { ... }
class ExampleImpl2 extends Example { ... }

def example() = new ExampleImpl1

then the return type of the method will be inferred to be ExampleImpl1 - so, it is exposing the fact that it is returning a specific implementation of trait Example . You can use an explicit return type to hide this:

def example(): Example = new ExampleImpl1

Answer 3

The standard rule is to use explicit types for API (in order to specify the type precisely and as a guard against refactoring) and also for implicits (especially because implicits without an explicit type may be ignored if the definition site is after the use site).

To the first question, type inference can be a significant tax, but that is balanced against the ease of both writing and reading expressions.

In the example, the type on the local list is not even a "better java." It's just visual clutter.

However, it should be easy to read the inferred type. Occasionally, I have to fire up the IDE just to tell me what is inferred.

By implication, methods should be short enough so that it's easy to scan for the result type.

Sorry for the lack of references. Maybe someone else will step forward; the topic is frequent on MLs and SO.

Answer 4

2. The scala style guide says

Use type inference where possible, but put clarity first, and favour explicitness in public APIs.

You should almost never annotate the type of a private field or a local variable, as their type will usually be immediately evident in their value:

private val name = "Daniel"

However, you may wish to still display the type where the assigned value has a complex or non-obvious form.

All public methods should have explicit type annotations. Type inference may break encapsulation in these cases, because it depends on internal method and class details. Without an explicit type, a change to the internals of a method or val could alter the public API of the class without warning, potentially breaking client code. Explicit type annotations can also help to improve compile times.

The twitter scala style guide says of method return types:

While Scala allows these to be omitted, such annotations provide good documentation: this is especially important for public methods. Where a method is not exposed and its return type obvious, omit them.

I think there's a broad consensus that explicit types should be used for public APIs, and shouldn't be used for most local variable declarations. When to use explicit types for "internal" methods is less clear-cut and more a matter of judgement; different organizations have different standards.

1. Type inference doesn't seem to visibly affect compilation time for the line where the inference happens (aside from a few rare cases with implicits which are basically compiler bugs) - after all, the compiler still has to check the type, which is pretty much the same calculation it would use to infer it. But if a method return type is inferred then anything using that method has to be recompiled when that method changes.

So inferring a method (or public variable) that's used in many places can slow down compilation (particularly if you're using incremental compilation). But inferring local or private variables, private methods, or public methods that are only used in one or two places, makes no (significant) difference.