Scalaコンパイラーがシールされていないクラス/トレイトに対してパターンマッチング警告を出せないのはなぜですか？

非シールtraitまたはabstract classScalaを使用してからパターンマッチングを使用する場合、コンパイラーはこの特定のパターンマッチのコンパイル時に、このトレイト/クラスの可能な実装が何であるかを知りませんか？だから、もしそうなら、可能性のあるすべての依存関係/インポートをチェックすることによって、使用できるタイプを知っているのでtrait/ abstract classがシールされていなくても、パターンマッチの警告を出せないでしょうか？

たとえば、私がに対してOption[A]パターンマッチングを行っているSome[A]が、に対してNoneは行わない場合、Optionはシールされているため、コンパイラは文句を言うでしょう。

コンパイラがそれを認識/解決できない場合、なぜ彼はそれができないのですか？そして、コンパイラーが（理論的に）それを実行できる場合、それがScalaで使用されない理由は何ですか？そのような動作をサポートする他の言語はありますか？

クラスのすべてのサブクラスを計算することはクラス階層分析と呼ばれ、動的コードロードを使用する言語で静的CHAを実行することは、停止問題を解決することと同じです。

さらに、Scalaの目標の1つは、独立したモジュールの個別のコンパイルとデプロイです。そのため、コンパイラーは、クラスが複数のモジュールを決して見ないため、クラスが別のモジュールでサブクラス化されているかどうかを知ることができません。（結局のところ、システムにモジュールが存在していなくても、他のモジュールのインターフェイスに対してモジュールをコンパイルできます！）そのためsealed、すべてのサブクラスを同じコンパイル単位で定義する必要があります。

これは、JVMがC ++コンパイラと非常に有利に競合できる理由の1つでもあります。C++コンパイラは通常、静的コンパイラであるため、メソッドがオーバーライドされているかどうかを概して判断できないため、インライン化できません。JVM OTOHは通常、動的コンパイラーであり、メソッドがオーバーライドされているかどうかを確認するためにCHAを実行する必要はありません。実行時にクラス階層を確認するだけです。そして、プログラムの実行後の時点で、以前にはなかった新しいサブクラスが発生したとしても、大した問題ではなく、インライン化せずにそのコードを再コンパイルするだけです。

注：これはすべてScala内でのみ適用されます。JVMにはの概念がないsealedため、別の言語に通信する方法がないため、別の JVM言語sealedからクラスをサブクラス化することは完全に可能です。プロパティはに記録されたアノテーションが、他の言語のコンパイラは、明らかに、考慮にこれらの注釈を取ることはありません。sealedScalaSig

これは（少なくともコンパイル時に既知のすべてのクラスに対して）実行できますが、コストがかかるだけです。他のファイルが変更されるたびに、パターンマッチを含むすべてを効果的に再コンパイルする必要があるため、増分コンパイルを完全に破棄します。

そして、あなたは何を買っていますか？新しい派生クラスが追加されたときに頻繁に変更する必要があるパターンマッチを記述するのはコードの匂いです。開閉の原則違反です。継承を適切に使用すれば、そのようなパターンマッチを記述する必要はありません。そして、はい、オープン/クローズの原則は、クラスベースの継承のない関数型言語にも適用されます。実際、型クラス、マルチメソッド、単純な高階関数などの機能の間では、関数型言語を使用することで、変更なしの拡張がはるかに簡単になります。