ネイティブプラットフォームと相互運用する場合、ポインタ操作に関して極めて特殊なコーディングパターンが必要となることがよくある。Cで記述したシム(shim)を経由すれば可能だが、 "Operators should be exposed for System.IntPtr and System.UIntPtr"と題した提案では，C#から直接提供する方法について論じている。
ポインタを直接操作する機能は、当初からCommon Language Runtime(CLR)に含まれていた。その名前が示すように、CLRは，C ++などの"低レベル"言語を含む，多種多様な言語をサポートするように設計されている。そのため、オリジナルの.NET言語であるVB，C＃，J＃，JScript.NET(後者2つは提供されなくなった)では不要な機能も含まれている。
提案では，加算，除算，乗算，剰余，減算，不等号，等号，比較、And、Not、XOr、ShiftLeft、ShiftRightという14個の演算子を取り上げている。提案によると，"CLI仕様で定義されている検証不可能(unverifiable)な演算子はリストに含まれておらず、現時点では本提案に含まれていません (ただし，考慮する価値はあると思われます)"。
CLI標準から引用されたこの一節には"検証可能(verifiable)"の意味が説明されているが，文書では取り上げていない。
型安全(type-safe)なコードと検証可能(verifiable)なコードの違いは証明可能性です。VES検証アルゴリズムをパスするコードは、その定義上，検証可能です。しかしVESの単純なアルゴリズムでは、より深い分析によって真に型安全であると明らかになったコードでも，拒否される場合があります。プログラムがパーティションVIに記載された構文に従っていたとしても，有効でない可能性は残っています。有効なコードはこのパーティションに加えて，パーティションIIIの制限にも準拠しなければならないからです。
検証プロセスは極めて厳密です。バリデーションにパスしても，検証に失敗するプログラムはたくさんあります。プログラムが許可されていないメモリやリソースにアクセスしないということを，VESでは保証できません。それにも関わらず，それらのプログラムは，そのようなリソースにアクセスしないように正しく構築されているかも知れません。つまり，プログラムの実行が安全かどうかは数学的な証明問題ではなく，信頼性の問題なのです。CLIに準拠した実装では、検証不可能なコード(検証に合格しない有効なコード)も通常は実行できますが、これはこの標準の一部ではなく，運用上の信頼管理の対象であると言えます。逆に，検証可能なコードの実行は当然可能ですが，これには実装特有の信頼性管理が必要な場合もあるのです。
おそらくこれらの操作は，アンセーフのコンテキストでのみ許されるものだろう。しかし提案では，これについて明示的に述べていない。
我々の"C# Future"シリーズの他の機能と同じく，この提案は現在検討中であり，C#ロードマップには含まれていない。