Add LDM notes for Feb. 10, 2020

meetings/2020/LDM-2020-02-10.md

@@ -0,0 +1,48 @@
+
+# C# Language Design for Feb. 10, 2020
+
+# Agenda
+
+Records
+
+# Discussion
+
+We're continuing our attempt to draw out the dependencies and individual features inside records.
+
+When going through the list, what stands out is:
+
+- Looking at `with`, we need to figure out what's mentionable in the `with` expression.
+
+- We need to figure out exactly what we want for how primary constructors fit into records
+
+There are a number of positives and negatives of primary constructors. On the negative side,
+a non-record primary constructor seems to consume syntactic space that could be used for
+records. If we think that records are the overwhelmingly common scenario, then it seems like
+using the shortest syntax for the most common feature is useful. On the positive side, primary
+constructors alone seem to support a simpler way of writing private implementation details.
+Separate from the value as a whole, there's some desire to have a special keyword just for
+records. That is, even if we didn't do primary constructors, it could be valuable to have
+an explicit modifier, like `data` to signify that this type has special behavior.
+
+One possible pivot is to eliminate some composition syntax entirely, by creating a new type
+of declaration, `record`, e.g.
+
+```C#
+record Point(int X, int Y);
+```
+
+This would be equivalent to the syntax that we've been discussing with `data`, namely
+
+```C#
+data class Point(int X, int Y);
+```
+
+but since the `class` keyword is implied by default, the most common scenario would be
+just about as short as the shorter `class Point(int X, int Y)` form.
+
+**Conclusion**
+
+After taking everything into account, we think having an new keyword for records is good both for
+leaving space for non-record primary constructors, and also to serve as a clear signifier of
+record semantics.
+