Common Type System/FCL/BCL にマッピングされていない特殊なデータ型を含む .NET に実装されたマネージプログラミング言語、または出荷された .NET の同等物 (たとえば、出荷された System のような標準型.文字列、System.Int32)?
この質問は、誰かがコンパイラを移植するという観点から来る可能性があります (私はそうしていませんが)。
特殊な型の BCL/FCL の外部で新しいデータ型を作成する言語と同じくらい単純ですか? そうであれば、Visual Basic や C# のように、すべての組み込みデータ型を BCL/FCL にマッピングすることに慣れているプログラミング言語間の相互運用性が妨げられますか?
このような状況は、暗黙のデータ型の 1 つが出荷されたフレームワークに直接マッピングされていない、ある種のあいまいな言語コンパイラが .NET に移植された場合に発生する可能性があると想像できます。
この状況は一般的にどのようにサポートまたは許可されていますか? コンパイラと共通言語ランタイムの期待は何ですか?
Delphi for .NETは、Delphi言語のクラス変数（クラス型への参照を保持できる）、仮想クラスメソッド、および仮想コンストラクター（クラス参照を介して呼び出される）の概念を実装しました。これらはいずれもCLRに直接類似していません。CLRの静的メソッドを仮想にすることはできず、コンストラクターを仮想にすることはできません。
CLRには実行時型情報が豊富に含まれているため、これらのアーティファクトはCLRで厳密に必要とされるわけではありません。コンパイル時に正確な型を知らないコードで実行時に型のインスタンスを構築したい場合は、リフレクションまたは他の手法を使用してそれを行うことができます。Delphi言語のこれらの機能は、実行時型情報が制限されているネイティブにコンパイルされたWin32製品から生まれました。これはすべて、DLRのようなものが登場するずっと前に、.NET1.0および1.1に実装されていました。
これらのDelphi言語機能は、リフレクションを使用してCLRでエミュレートできますが、パフォーマンス上の理由から、Delphiで宣言されたすべてのクラスタイプのサイドカーである「メタクラス」タイプを作成することにより、ILで直接実装することを選択しました。DelphiコードがDelphiクラスタイプをクラス参照変数に割り当てた場合、対応するメタクラスのシングルトンインスタンスを変数に割り当てるためのILコードを生成しました。クラス参照変数を介した仮想メソッド呼び出しは、メタクラスインスタンスでのIL仮想メソッド呼び出しとしてコード生成され、対応するクラスタイプの実際の静的メソッド実装にバウンスされました。これにより、クラス仮想メソッド呼び出しは、実行時のパフォーマンスコストを最小限に抑えながら、多態的に動作し（呼び出しに使用されるインスタンスのタイプに適した実装を呼び出すことができます）、
これらの仮想クラスメソッドの機能は、Delphi構文で宣言されたクラスにのみ適用可能であり、Delphi構文でのみ使用できます。Delphiで作成されたクラスを使用するときに、他の.NET言語が（ほとんどの場合）それらを無視するように、メタタイプは非CLS準拠としてマークされていると思います。他の.NET言語は、これらのDelphi固有の言語機能を利用できませんでした（開発者が実際に決定され、醜い名前のメタクラスを介して適切な呼び出しを行うために足場を登っていない限り）
一般に、他の言語があなたの言語によって/のために作成された非CLSアーティファクトを利用することを期待するべきではありません。他の言語で自分の言語で作成されたものを利用したい場合は、CLS準拠の用語で合理的な方法で表現できる方法で特別なソースを表現する方法を理解する必要があります。特製タレの性質によっては、それができない場合があります。
Delphi仮想クラスメソッドは、通常の静的メソッドとして他の.NET言語で使用できました。主にCLS（または他の言語）が概念を表現できないため、多形性は他の.NET言語に公開されませんでした。
理想的には、すべての言語が考えられるすべての構成を等しくうまく表現できるでしょう。しかし実際にはそうではありません。一部のグラフ関数はデカルト座標で表現するのが簡単ですが、他のグラフ関数は極座標を使用することで大幅に簡略化されています。同じことがプログラミング言語にも当てはまります。
CLRに実装されている場合でも、独自の言語で新しい表現手段を発明することは問題ありません。言語のコードが他の人から呼び出されることを期待する場合は、言語の外部で作業するプログラマーにとって、型がどのように見えるかを明確に定義してください。あなたの実装には二重性があります：あなたの言語のユーザーに物事がどのように見えるか、そしてあなたの言語の外のユーザーに物事がどのように見えるかです。
脚注：これは、.NET用の新しいDelphi製品であるDelphiPrismには当てはまらないと思います。DelphiPrismは仮想クラスメソッドをサポートしていないと思います。
あまり。どんな言語でも、成功するためにはコモディティ ハードウェア上で実行できなければならないという究極の負担があります。CTS は、現在のハードウェアで効率的に処理できる型の非常に優れたモデルです。
必要になる可能性があるのは、言語の型システムと CLI の間で適応するためのランタイム サポートの大部分です。古典的な例は、Python や Ruby などの動的言語のランタイム サポート システムである DLR です。基本的に、そのような言語インタープリターが行う必要があることも行います。同等のパフォーマンスがあります。ところで、トリックはありません。すべてが純粋な C# コードです。
このようなランタイム サポート ライブラリは、言語にまったく利用できない機能がある場合、遅くなる可能性があります。たとえば多重継承。これは、CLR および JIT コンパイラによってネイティブに「サポート」されています。MI を使用する標準に準拠した C++ プログラムを取り、/clr オプションを指定して C++ コンパイラで実行すると、実行時にジャストインタイム コンパイルされる純粋な IL を含むアセンブリになります。その結果をマネージド プログラムと呼ぶことは想像に難くありません。それは検証可能ではなく、ガベージ コレクターを使用しません。これを解決するには、多重継承をエミュレートする必要があるサポート ライブラリが必要になります。可能ですが、競争力があるとは思えません。
さて、c++/cli があります。そこでは、.net では表示されない C++ クラスを作成できます。それはあなたが求めているものですか？