Scalaでリストに追加するのにO（n）時間の複雑さがあるのはなぜですか？

List（：+）の追加操作の実行時間は、のサイズに比例して増加することを読みましたList。

に追加することListは、かなり一般的な操作のようです。なぜこれを行う慣用的な方法がコンポーネントを前に付けてからリストを逆にする必要があるのですか？実装はいつでも変更される可能性があるため、設計の失敗にもなりません。

私の観点からは、先頭と末尾の両方がO（1）である必要があります。

これには正当な理由がありますか？

コメントを少し拡大します。からのList[T]データ構造scala.collection.immutableは、より純粋に機能的なプログラミング言語の不変リストが機能するように最適化されています。プリペンド時間は非常に高速であり、アクセスのほとんどすべてについて頭で作業することを想定しています。

不変リストは、リンクリストを一連の「コンスセル」としてモデル化するという事実により、非常に高速のプリペンド時間を持ちます。セルは、単一の値と、次のセルへのポインターを定義します（古典的な単一リンクリストスタイル）：

Cell [Value| -> Nil]

リストの先頭に追加する場合、実際には1つの新しいセルを作成するだけで、既存のリストの残りの部分は次のように示されます。

Cell [NewValue| -> [Cell[Value| -> Nil]]

リストは不変であるため、実際にコピーすることなくこれを実行しても安全です。古いリストが変更され、新しいリストのすべての値が無効になる危険性はありません。ただし、への可変ポインタを持つ能力を失う妥協案としてリスト末尾れます。

これは、リストの再帰的な作業に非常に役立ちます。独自のバージョンを定義したとしましょうfilter：

def deleteIf[T](list : List[T])(f : T => Boolean): List[T] = list match {
  case Nil => Nil
  case (x::xs) => f(x) match {
    case true => deleteIf(xs)(f)
    case false => x :: deleteIf(xs)(f)
  }
}

これは、リストの先頭からのみ機能する再帰関数であり、::抽出機能を介したパターンマッチングを利用します。これは、Haskellのような言語でよく目にするものです。

本当に高速な追加が必要な場合、Scalaは、選択可能な可変および不変のデータ構造を多数提供します。可変側では、を調べることができますListBuffer。または、Vectorfromのscala.collection.immutable追加時間は高速です。