Add LDM notes for 2019-09-16

meetings/2019/LDM-2019-09-16.md

@@ -0,0 +1,121 @@
+
+# C# Language Design Meeting for September 16, 2019
+
+## Agenda
+
+1. UTF-8 strings (https://github.com/dotnet/corefxlab/issues/2350)
+2. Triage
+
+## Discussion
+
+### UTF-8 Strings
+
+Motivation: UTF-8 is everywhere, and converting to and from the .NET native string type (UCS2/UTF-16),
+can be expensive and confusing.
+
+#### Language impact
+
+**Literals**
+
+Current proposal is to emit the data as UTF-16, and use a runtime helper to project to UTF-8. The
+main question for the language is if this encoding limits the usability in some way, and whether
+it blocks us off from introducing an optimal strategy later. There are two things to consider: the
+cost in the compiler, and the cost to the language. At the moment we don't see anything that would
+be considered a breaking change in the language.
+
+**Enumeration**
+
+The proposal doesn't include any default enumeration. It's worth considering if this violates C#
+user expectations. There are different forms of enumeration available by calling properties, but
+none of them are the default. Should there be a default?
+
+One problem is that users who see enumeration may expect indexing, which is not cheap, and does
+not match expectations. Another problem is that there is almost always a better operation than
+enumerating a UTF-8 string. It seems like adding this more likely to encourage a user to write a
+bug, or inefficient code, than to help them.
+
+**Why language support**
+
+The main advantages of language support are:
+
+* O(n) string concatenation (calling utf8string.Concat with all `n` arguments)
+* String literals
+
+**Target-typing**
+
+Target-typing of existing string literals is possible but produces "bad" behavior for seemingly
+the most common scenario:
+
+```C#
+void M(string s) { ... }
+void M(Utf8String s) { ... }
+
+M("some string"); // This would call the `string` version, because backwards compatibility requires
+                  // "" always be a `string` first, and a `Utf8String` second
+```
+
+**Syntax**
+
+As always, there's debate about the syntax. The "u" prefix is somewhat unsatisfying because UTF-8,
+UTF-16, UCS-2, *and* `unsigned` all begin with "u". The same complaints hold for the proposed
+`ustring` contextual keyword. However, there are no enthusiastically favored alternatives.
+
+In addition, the value of the `ustring` contextual keyword seems questionable. If the brevity is
+important, then it seems important enough that the framework could call it `ustring` or `utf8`.
+One argument is that Utf8String could be a new "primitive" type, and we should add a keyword for
+all primitive types. However, this is not proposed as a primitive type at the same level, so that
+weakens support. In addition, the original aliases were all added at the inception of the language,
+so we have no precedence for adding either primitive types or aliases.
+
+**Conclusion**
+
+We think the feature is valuable and probably worth some language support. We think a literal syntax
+(like the "u" prefix) is good, but we don't like target typing. We're also not convinced of the need
+for a contextual keyword.
+
+### More triage
+
+#### Null parameter checking
+
+Issue #2145
+
+ASAP, 9.0
+
+### CallerArgumentExpression
+
+Issue #287
+
+We could potentially use this to implement "Null parameter checking" as a method call, instead of
+new syntax. Thus, consider for 9.0.
+
+### Relax ordering constraints about modifiers (especially `ref` and `partial`)
+
+Issue #946
+
+9.0
+
+### Zero- and one-element tuples
+
+Issue #883
+
+In terms of language value, zero- and one-element tuples are different features. Zero-element
+tuples are most useful as a unit type, which is not necessarily the unit type we would choose
+to standardize on (e.g. against System.Void), while one-element tuples are simply useful as a
+wrapper type and don't have an obvious competitor.
+
+We need to revisit the decisions here. Moving to X.X
+
+### Mix declarations and variable in deconstruction
+
+Issue #125
+
+Not an urgent feature, but useful for completeness. On the other hand, it's always very clear
+whether or not the deconstruction is using existing variables, or creating new ones.
+
+Any time
+
+### Discard for lambda parameters
+
+Issue #111
+
+Any time

meetings/2019/README.md

@@ -35,11 +35,6 @@
     - https://github.com/dotnet/csharplang/issues/2632 Champion: Switch expression as a statement expression
     - https://github.com/dotnet/csharplang/issues/2608 module initializers
 
-## Sep 16, 2019
-
-- Support for Utf8 strings (https://github.com/dotnet/corefxlab/issues/2350) (Levi)
-- Triage remaining features out of the [8.X milestone](https://github.com/dotnet/csharplang/issues?q=is%3Aopen+is%3Aissue+milestone%3A%228.X+candidate%22)
-
 ## Aug 26, 2019
 
 - Triage language features
@@ -57,6 +52,13 @@
 
 Overview of meetings and agendas for 2019
 
+## Sep 16, 2019
+
+[C# Language Design Notes for Sep 16, 2019](LDM-2019-09-16.md)
+
+- Support for Utf8 strings
+- Triage remaining features out of the [8.X milestone](https://github.com/dotnet/csharplang/issues?q=is%3Aopen+is%3Aissue+milestone%3A%228.X+candidate%22)
+
 ## Sep 11, 2019
 
 [C# Language Design Notes for Sep 11, 2019](LDM-2019-09-11.md)