scala - returnステートメントを回避する理由はありますか

Question

いくつかのネストされたレベルの条件とマッチングを含むScalaコードのチャンクが表示されることがあります。これは、関数を終了するための明示的な戻りを使用すると、はるかに明確になります。

これらの明示的なreturnステートメントを回避することに何か利点はありますか？

Answer 1

Aは例外をスローするreturn ことで実装できるため、メソッドの結果を宣言する標準的な方法よりも一定のオーバーヘッドが発生する可能性があります。（これを指摘してくれたKim Stebelに感謝します。必ずしもそうとは限りませんが、頻繁ではないかもしれません。）

また、 onクロージャーは、単にクロージャー自体からではなく、クロージャーが定義されてreturnいるメソッドから戻ります。これは、そのために役立つだけでなく、クロージャから結果を返すのにも役立ちません。

上記の例：

def find[T](seq: Seq[T], predicate: T => Boolean): Option[T] = {
  seq foreach { elem =>
    if (predicate(elem)) return Some(elem) // returns from find
  }
  None
}

それでもわからない場合は、の匿名オブジェクトのelem => if (predicate(elem)) return Some(elem)メソッドが実装され、パラメータとして渡されます。それから削除すると、動作しません。applyFunction1foreachreturn

Answer 2

1つの欠点は、戻りタイプを推測できないことです。他のすべてはスタイルの問題です。あなたにとって不明瞭または混乱しているように見えることは、他の誰かにとって完全に「自然」である可能性があります。

Answer 3

明示的な戻りは、制御フローを中断します。たとえば、次のようなステートメントがある場合

if(isAuth(user)) {
 return getProfile(user)
}
else {
 return None
}

制御構造（if）が完成していないので、もっと混乱していると私は主張します。私にとって、これはbreakステートメントに似ています。さらに、Scalasの「すべてが値である」という原則により、明示的な戻り値を使用する必要性が減り、defステートメントにのみ役立つキーワードを使用する人が少なくなります。

// start 
def someString:String = return "somestring"

// def without return 
def someString = "somestring"

// after refactoring
val someString = "somestring"    

タイプアノテーションを追加する必要があり、defをvalに変更するときは、戻り値を削除する必要があることがわかります。