csharplang/meetings/2017/LDM-2017-06-13.md

C# Language Design Notes for Jun 13, 2017

Agenda

1. Native-size ints
2. Native-size floats

Native-size ints

We want nint and nuint to be part of the language. They will be used in contexts where we care about respecting checked vs unchecked in operator behavior, for example.

We have two options for how to represent at runtime:

1. Project to IntPtr, track the nint or nuint "overlay" in metadata for compile-time consumption only
2. Project to new struct types that wrap an IntPtr and potentially exhibit different behavior at runtime too

Option 2 had some objections attached. Let's go through them:

• Adoption/roll out of new types would take time
  • We could embed these struct types in the generated assembly and use the NoPIA machinery to unify them across assemblies.
• Would have a slight cost on IL size.
  • Probably not a decisive objection
• Need new overloads for a few things, such as Interlocked.CompareExchange
  • We could probably live with those rolling out gradually, especially with access to the IntPtr of a nint or nuint as a public field (so it can be passed by ref to existing overloads)
• There is a bifurcation because the types are really distinct at runtime. There's interop pain between them.
  • This may be a good thing. Arguably they represent different concepts: IntPtr is more of an opaque handle, whereas nint and nuint are real integers with number semantics.

Option 1 has some objections as well:

• ToString doesn't work right
  • This could probably be fixed. It is unlikely that the current deficiencies are depended upon
• you lose context on box/unbox
  • That is already the case today with other common types, such as tuples, nullable value types and dynamic. Is it really so bad?
• Imprecise reflection info
  • Again, we live with this in many places

String.Format would exhibit the combination of the first and second problem: passing a nint as an argument, it would box and lose context, so IntPtr.ToString would get called.

Things to ponder regardless of implementation strategy:

• Conversions: Should there be conversions between nint/nuint and IntPtr? If so, which way (if any) should be implicit?
• Upgrade: Someone using IntPtr today might want to switch to nint. This would mostly just work, but would have very subtle changes of behavior here and there.

Conclusion

We are still hung on what to do. We want to more deeply understand objections against Option 1, and understand if mitigations considered would address e.g. Xamarin's concerns.

Native-size floats

Float really is a different discussion. Language embedding is less significant: we don't have a notion of checked/unchecked. The main objective would just be to have an alias.