Add LDM notes for Oct. 23, 2019

meetings/2019/LDM-2019-10-23.md

@@ -0,0 +1,92 @@
+
+# C# Language Design Meeting for Oct. 23, 2019
+
+## Agenda
+
+1. New primitive types (`nint` and `nuint`)
+
+## Discussion
+
+### Native int
+
+Proposal: https://github.com/dotnet/csharplang/issues/435 
+
+#### Static members
+
+The current spec states that `nint` and `nuint` are reserved keywords in a type context but there
+are contexts, like qualified names, that allow types but are not type contexts. Since `nint` and
+`nuint` have static members, we want users to be able to access them, so they should be allowed
+in qualified names.
+
+#### IntPtr members
+
+A follow-up question is what to do about existing members on the underlying IntPtr
+type. There are some members, like Add and Subtract, which may be misleading because
+they are not equivalent to `+` and `-` due to over/underflow checking.
+
+There are two views here. On the one hand, the proposal to use IntPtr means that
+some implementation details for IntPtr will inevitably leak through. Since users
+will sometimes want to use an IntPtr as an `nuint` to do pointer arithmetic, any
+methods on IntPtr may be useful and this would just be making barriers.
+
+On the other hand, `nint` is being added as a type for conceptually different reasons. It
+shouldn't be assumed that everything that applies to IntPtr should be applicable to `nint`.
+There's a follow-up question as whether we would exclude everything on IntPtr except for an
+include list, or include everything except for an exclude list. These may seem very different,
+but after more thought it's likely they're very similar. Since the framework would probably very
+rarely add new members to IntPtr after the language change (like with System.Int32), what we pick
+now is probably what will be present for a very long time, and anything new would probably be
+done with consultation from the language team.
+
+Our tentative conclusion is that we should exclude some members. The following
+are questionable:
+
+* Zero (use the `0` literal)
+* Size (use sizeof)
+* Add, Subtract (part of the point of this type is to use "proper" C# arithmetic)
+* ToInt32, ToInt64, ToPointer (use the language-defined conversions)
+
+#### Signed bitwise operations
+
+Unfortunately, IntPtr is "signed" but is often used to represent pointers, which are unsigned
+according to framework guidelines. In the current design, IntPtr has an identity conversion to
+`nint`, which could cause the unfortunate scenario
+
+```C#
+IntPtr M(IntPtr p)
+{
+    nint x = p;
+    x >> 1;
+    return x;
+}
+```
+
+This would use signed `>>`, which is probably incorrect if the value is assumed to be an unsigned
+pointer. This is not currently a problem with IntPtr because IntPtr does not define any bitwise
+operators.
+
+Unfortunately, keeping an identity conversion is an important part of compatibility. We would
+like to support users who are currently using IntPtr, but would like to use `nint`, to go from
+`IntPtr[]` to `nint[]`. Without an identity conversion, we don't see how this would be possible
+in the language today.
+
+Adding an entirely new concept in the language to support this without identity conversions is
+probably not worth it. Unless we can find a simple improvement to the design, we will probably
+have to accept this behavior.
+
+#### Overriding, hiding, and implementation (OHI)
+
+Since IntPtr and nint are the same CLR underlying type, they will be regarded as having the same
+signature. The compiler is able to see the difference. Should we regard them as identical for the
+purposes of OHI? This is similar to scenarios like tuple names, which are represented as
+attributes and thus not visible as part of the CLR type. However, in OHI we provide an error if
+tuple names change in an override because this could be the source of a bug (e.g., if the names
+were accidentally swapped). In this case we think IntPtr and `nint` are similar enough that we
+should regard the OHI behavior similar to `dynamic`/`object`, where it is allowed.
+
+For use as an enum underlying type, we think `nint`/`nuint` should be allowed as long as it's not
+too much implementation work. The legal values would be the same as the valid constants for the
+underlying.
+
+For sizeof, we think it should be supported in unsafe code, just like `sizeof(IntPtr)`, but with
+no special behavior in safe code.

meetings/2019/README.md

@@ -42,14 +42,18 @@
 - https://github.com/dotnet/csharplang/issues/111 Confirm whether discard parameters are allowed in methods and local function, confirm scoping behavior (Julien)
 - https://github.com/dotnet/csharplang/issues/2823 Enhancing the Common Type Specification (Neal)
 
-## Oct 23, 2019
-
-- https://github.com/dotnet/csharplang/issues/435 Native-sized ints (Chuck, Jared)
-
 # C# Language Design Notes for 2019
 
 Overview of meetings and agendas for 2019
 
+## Oct 23, 2019
+
+[C# Language Design Notes for Oct 23, 2019](LDM-2019-10-23.md)
+
+1. New primitive types 
+
+https://github.com/dotnet/csharplang/issues/435
+
 ## Oct 21, 2019
 
 [C# Language Design Notes for Oct 21, 2019](LDM-2019-10-21.md)