Added LDM notes for 2020-04-01

meetings/2020/LDM-2020-04-01.md

@@ -0,0 +1,119 @@
+
+# C# Language Design Meeting for April 1, 2020
+
+## Agenda
+
+1. Function pointer calling conventions
+
+2. `field` keyword in properties
+
+## Discussion
+
+### Function Pointers
+
+There are a few open issues and proposals for generalization of function pointers based on
+new runtime features.
+
+https://github.com/dotnet/csharplang/issues/3324
+
+#### NativeCallableAttribute
+
+The attribute already exists in the CLR, and allows for specifying a calling convention other than
+`managed` (which means that it can't be called from C#, but could be used from function pointers).
+
+The question is what level of support we want to provide in the language for this attribute.
+
+Since the runtime behavior is to crash if the method is called incorrectly (meaning, invoked at
+all from C# if not through a function pointer), we almost certainly want to recognize the
+attribute's existence and provide errors for incorrect usage.
+
+We considered more restrictions than the ones mentioned in the issue (only usable in function
+pointers, parameters must be blittable, must be static) like restricted accessibility or special
+syntax. The consensus is that is too much work for a small feature.
+
+**Conclusion**
+
+`NativeCallableAttribute` should be recognized and the restrictions are accepted, with the
+addition that generics are also prohibited in the method and all containing types, recursively,
+and delegate conversion is also prohibited.
+
+#### Supporting extra calling conventions
+
+The existing proposal mandates that the only the existing calling conventions are supported. We
+previously said we'd consider new calling conventions when they were proposed by the runtime. We now
+have proposals about some likely new calling convention from the runtime.
+
+The proposal is that the "calling convention" syntax in function pointers could be a general identifier, and legal values for the runtime would be determined by name matching against type names
+starting with `CallConv` in a particular namespace, and passing through Unicode lower-case mapping.
+
+**Conclusion**
+
+Accepted.
+
+#### Attributes on function pointer types
+
+The syntax is getting a bit verbose, but allowing an extra axis for customization seems like the
+simplest extension of function pointers that provides the level support that the runtime may need
+in the future.
+
+Currently our favored syntax is:
+
+```C#
+delegate* cdecl[SuppressGCTransition, MyFuncAttr]<void> ptr;
+```
+
+The attribute-like syntax would be turned into the `modreq`s on the function pointer type that
+would be used by the runtime to encode special calling behavior. These would also effectively be
+different types at the C# level and would not have implicit conversions between them.
+
+**Conclusion**
+
+Accepted, assuming there are no problems in implementation.
+
+### `field` keyword in properties
+
+Over the years there have been many requests for similar features, e.g.
+https://github.com/dotnet/csharplang/issues/140
+
+Maybe the simplest version is that there is a contextual identifier, e.g. `field`, which refers
+to an implicit backing field of the property. This seems useful, but a big limitation is that the
+backing field of the property must have the same type as the property. If lazy initialization is
+a common case, that seems likely to require differing property types, as the backing field would
+often be nullable, but the initialized field would be not nullable.
+
+On the other hand, biting off too much in a single feature may delay simple scenarios
+unnecessarily. Should we try to address the simplest scenarios first, and leave more complex
+scenarios for later? In this case we probably need to find what scenarios are served by that
+design. Two things that are recognized are simple validation, e.g.
+
+```C#
+public int PositiveValue
+{
+    get => field;
+    set
+    {
+         if (value < 0)
+            throw new ArgumentException("Cannot be negative")
+        field = value;
+    }
+}
+```
+
+and registration like `INotifyPropertyChanged`
+
+```C#
+public int P
+{
+    get => field;
+    set
+    {
+        PropertyChanged();
+        field = value;
+    }
+}
+```
+
+Let's confirm that these scenarios are the ones most commonly requested and that they aren't
+addressed or modified by any of the other scheduled language features, e.g. source generators for
+INotifyPropertyChanged. From there we can discuss the specific proposal with a better
+understanding of the problem and solution space.

meetings/2020/README.md

@@ -32,11 +32,6 @@ https://github.com/dotnet/csharplang/issues/3301 Non-void and non-private partia
 
 - Record Monday (Andy, Mads)
 
-## April 1, 2020
-
-- https://github.com/dotnet/csharplang/issues/3324    Function pointer calling conventions (frsilb)
-- https://github.com/dotnet/csharplang/issues/140 `field` keyword in properties (cyrusn)
-
 ## March 18, 2020
 
 - https://github.com/jaredpar/csharplang/blob/record/proposals/recordsv3.md clone-style records (Jared)
@@ -57,6 +52,14 @@ https://github.com/dotnet/csharplang/issues/3301 Non-void and non-private partia
 
 Overview of meetings and agendas for 2020
 
+## April 1, 2020
+
+[C# Language Design Notes for April 1, 2020](https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-04-01.md)
+
+1. Function pointer design adjustments
+
+2. `field` keyword in properties
+
 ## March 30, 2020
 
 1. Record Monday