Added: C# Language Design Notes for May 26, 2017

[MadsTorgersen]

C# Language Design Notes for May 26, 2017

1. Native ints

Please discuss.

[tannergooding]

Option 1 (Improve IntPtr with operators) could distinguish between checked/unchecked contexts if we did: #686

Some of the "weaknesses" of IntPtr can be fixed independently of operators: https://github.com/dotnet/corefx/issues/20256

[tannergooding]

Another objection for 3.2 is that the less efficient/more verbose IL may impact inlining scenarios in the JIT.

[tannergooding]

I think as for the objections to 3.1:

No runtime distinction (reflection and ToString)

Reflection can distinguish, in the same way it distinguishes Dynamic. Users would just need to "know" to look (if it matters in those scenarios).

ToString happens all the time

Not quite sure what the inefficiency here is. It just calls int.ToString or long.ToString, depending on the platform you are targeting (32 vs 64).

[tannergooding]

I think for the objections to 3.2:

Needing new overloads for nint where there are IntPtr overloads today (or at least a conversion, and new overloads where there are ref IntPtr parameters).

At least on CoreCLR, users can use the System.Runtime.CompilerServices.Unsafe class to work with ref IntPtr and can probably use Span<T> to work with IntPtr[]. No equivalent exists on Desktop as of yet.

[miloush]

I am in favor of 3.2. The objections are short-term only, apart from more verbose IL in "couple of cases", but those cases aren't elaborated on. Common cases? Corner cases?

[tannergooding]

@miloush, the actual struct would just be a wrapper around IntPtr, so anything that wraps an existing IntPtr function would end up being emitted as a call to the wrapping struct rather than a direct call to IntPtr.

This means the JIT has to work 'harder' to inline all these calls (the JIT is generally pretty good about simple wrappers, but there are a few issues where it fails to do the job and it causes significant drops in perf). It also means there is potential IL "bloat", which can impact the JIT in other unforeseen ways (in some cases it could make the method "just big enough" that inlining no longer happens for certain functions).

Most of these issues could be worked around, but there may be issues that would require a runtime fix (which means lower perf anywhere these fixes don't exist).

[miloush]

@tannergooding this does not sound like any existing code would be impacted, more like that a new feature would not be as performant as it theoretically could be, at least at the beginning. That's not a perf drop, that's an initial perf of a new feature which could be later improved upon.

[tannergooding]

@miloush, it is new to C# code certainly, but it is not new to the CLR or to any language which does expose the actual operators defined by the runtime spec (such as F# or raw IL).

The reason why I, personally, am less favorable of 3.2 are:

• It can potentially impact inlining
• It puts more overhead on the JIT to support something which it already provides native support for
• It prevents interop with certain types of existing code (or at the very least makes it significantly more difficult)
  • This includes ref IntPtr, out IntPtr, and IntPtr[], but also extends to requiring additional casts for IntPtr and IntPtr*

and, possibly most importantly; due to the reach of C#, it being used as the primary language for developing CoreFX, etc:

• Any other language that already supports this feature (F#, IL, possibly others) now has to code in two methods of supporting IntPtr operators.
  • F# already supports operators directly on IntPtr, if it wants to interop with code produced by C#, it will need to now recognize this second type. Where-as partial erasure means that it can add additional support if needed or leave it alone and things should just work
• Any other language that is looking at adding this feature either has to code two methods of supporting operators or they have to opt-in-to the poorer behavior that C# is now exposing.

[MillKaDe]

Quote from LD notes:

Options:

1. Improve [U]IntPtr with operators
2. Add nint and nuint as a user defined struct (the Xamarin approach)
3. Add nint and nuint to the language
   3.1. compile down to IntPtr and add an attribute to persist the additional type info in metadata
   3.2. project language-level types to new user defined structs
4. A combo of 1 and 3

What about "Option 5" =

• Option 1: (Improve IntPtr with (missing) operators)
  plus
• Option 3.3: define n[u]int as alias for System.[U]IntPtr (just like [u]int for System.[U]Int32)

That means:

• no extra structs (option 2),
• no extra metadata (option 3.1),
• no overloads on nint vs. IntPtr, cause they are the same type.

Note that the following 3 overloads would still be possible:

• void Foo (Int32 i) { ... } // int
• void Foo (Int64 i) { ... } // long
• void Foo (IntPtr i) { ... } // nint

.. since nint/IntPtr is neither the same type as int/Int32 nor long/Int64.

I don't understand, why / when / where the extra struct types would be needed ?

[tannergooding]

NOTE: The examples below are just examples and may not entirely be what LDM has in mind for that particular option.

@MillKaDe, many of the existing methods on IntPtr have predefined semantics/behavior that existing applications may be dependent on (the operators were added in net40, I believe the constructors have always been forced checked/unchecked).

The C# language can't just make IntPtr "work" because that could break existing applications (and worse, it would do so silently on recompile).

Option 3 is effectively what you are proposing minus the required metadata/attribute (Also, I'm fairly certain 3.1 and 3.2 are not sub-options but further details on the existing option).

Under option 3, if the user were to declare void MyMethod(IntPtr x) it would emit as void MyMethod(IntPtr x) and if the user were to declare void MyMethod(nint x) it would emit as void MyMethod([MagicAttribute] IntPtr x) (under option 2, it would emit as void MyMethod(nint x)).

Because attributes are not used in determining the method signature, you could not declare both void MyMethod(IntPtr) and void MyMethod(nint) (where-as you could if you did option 2 and created a new type nint).

The magic attribute is what allows the compiler to explicitly determine that a referenced assembly is going to be operating under the new semantics and that the user should explicitly cast when calling the method so that they are aware of the semantic differences.

For example, if the user has an nint x and wants to call void MyMethod(IntPtr x), they have to do MyMethod((IntPtr)(x)) and likewise, if they have IntPtr x but want to call void MyMethod(nint x), they have to do MyMethod((nint)(x)).

If you went with option 2 (new struct wrapper types), you would be in the same scenario (requiring an explicit cast to opt-in to the new semantics). The difference being that with option 3 ref, out, and [] types are convertible between IntPtr and nint (due to them being identical types). With option 2 this would not be possible (at least not without significant compiler magic and without breaking any exiting IL verification that the type passed in matches the type expected).

Both options (3 and 2) would also require, for existing methods that take IntPtr but want to operate with the new semantics, users to create a temporary local in their C# code:

static IntPtr Add(IntPtr left, IntPtr right)
{
    return (nint)(left) + (nint)(right);
}

Under option 3, this is only required syntax in the C# code, the IL that is produced can be identical to as if the user had just declared:

static nint Add(nint left, nint right)
{
    return left + right;
}

Now it might be the case that option 2 could be done and the compiler could do a bunch of optimizations to ensure the IL produced is as minimal as possible (accessing the wrapped IntPtr field directly, etc) and that removes most of the concerns I have already listed. But it still leaves:

• Possible issues with ref, out, and [] parameters
• Other languages now having to deal and work with a secondary native int type (effectively having to recognize and implement all the same optimizations the C# compiler has to in order to ensure performant code is generated).