
# 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