2.7 KiB
C# Language Design Notes for Jun 13, 2017
Agenda
- Native-size ints
- 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:
- Project to
IntPtr
, track thenint
ornuint
"overlay" in metadata for compile-time consumption only - 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 anint
ornuint
as a public field (so it can be passed byref
to existing overloads)
- We could probably live with those rolling out gradually, especially with access to the
- 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, whereasnint
andnuint
are real integers with number semantics.
- This may be a good thing. Arguably they represent different concepts:
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?
- That is already the case today with other common types, such as tuples, nullable value types and
- 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
andIntPtr
? If so, which way (if any) should be implicit? - Upgrade: Someone using
IntPtr
today might want to switch tonint
. 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.