Interoperability with native platforms often require very specific coding patterns that involve the manipulation of pointers. While this can be done via a shim written in C, the proposal titled Operators should be exposed for System.IntPtr and System.UIntPtr seeks to offer that ability directly in C#.
The ability to directly manipulate pointers has always been part of the Common Language Runtime (CLR). As the name suggests, the CLR was designed to support a wide variety of languages including “low level” languages such as C++. As such, it includes things not deemed necessary by the original .NET languages: VB, C#, J#, and JScript.NET (the latter two are no longer offered).
Fourteen operators are covered by this proposal: Add, Divide, Multiply, Remainder, Subtract, Negate, Equals, Compare, And, Not, Or, XOr, ShiftLeft, ShiftRight. The proposal claims, “The unverifiable operators defined by the CLI spec are not listed and are not currently part of this proposal (although it may be worth considering these as well).”
This statement is not elaborated on, though this passage from the CLI standard explains the meaning of “verifiable”,
The difference between type-safe code and verifiable code is one of provability: code which passes the VES verification algorithm is, by-definition, verifiable; but that simple algorithm rejects certain code, even though a deeper analysis would reveal it as genuinely type-safe. Note that even if a program follows the syntax described in Partition VI, the code might still not be valid, because valid code shall adhere to restrictions presented in this Partition and in Partition III.
The verification process is very stringent. There are many programs that will pass validation, but will fail verification. The VES cannot guarantee that these programs do not access memory or resources to which they are not granted access. Nonetheless, they might have been correctly constructed so that they do not access these resources. It is thus a matter of trust, rather than mathematical proof, whether it is safe to run these programs. Ordinarily, a conforming implementation of the CLI can allow unverifiable code (valid code that does not pass verification) to be executed, although this can be subject to administrative trust controls that are not part of this standard. A conforming implementation of the CLI shall allow the execution of verifiable code, although this can be subject to additional implementation-specified trust controls.
Presumably these operations would only be allowed in an unsafe context. However, the proposal doesn’t explicitly state this.
As with other features in our C# Futures series, this proposal is under consideration and not yet part of the C# road map.