# C# Language Design Meeting for June 29th, 2022

## Agenda

- [UTF-8 literal concatenation operator](#utf-8-literal-concatenation-operator)

## Quote of the Day

- "This is an example of our admirable quality that no stone is left unturned"

## Discussion

### UTF-8 literal concatenation operator

https://github.com/dotnet/csharplang/issues/184  
https://github.com/dotnet/csharplang/pull/6221

Today, we looked at a small proposal update for UTF-8 strings, based on BCL dogfooding feedback: the ability to concatenate UTF-8 string literals
together with the `+` operator so that long strings can be split across lines. This is similar to the work with interpolated string handlers, where
we similarly enabled the `+` operator for splitting strings across lines. We had two main discussion points:

First, should we enable `+` as a general operator on all `ReadOnlySpan<byte>`s? For example, should the following code work?

```cs
ReadOnlySpan<byte> M() => "hello "u8;
var helloWorld = M() + "world"u8;
```

We don't think that is a general case we want to support: concatenation of literals can be done easily at compile time, but this would need a general
ability to add `ReadOnlySpan<byte>`s together, and we don't know how that would work. Where would the resulting byte sequence live, for example, and
what would be its lifetime?

Second, we thought about whether this operator should have precedence over a user-defined operator `+` on `ReadOnlySpan<T>`? According to the C# spec,
all existing predefined operators in C# _do not_ have precedence over user-defined operators. However, this is not how the compiler is actually
implemented: the native C# compiler had a bug that always used predefined operators, even when the underlying type defined a `+` operator itself, and
Roslyn reimplemented that bug during its creation. When implementing the `+` predefined operator for `ReadOnlySpan<byte>`, however, we did not
carry that bug forward, so if a user defines their own `ReadOnlySpan<T>` with a `+(ReadOnlySpan<T> left, ReadOnlySpan<T> right)` operator defined on
it, that operator will be preferred over this predefined one. We could go and reimplement the bug for this case as well, but we don't think the
scenario is important enough to spend the time, and it will simplify the spec if we continue to specify predefined operators exactly as they are today,
rather than carving out a special case for this `+` operator.

#### Conclusion

Proposal accepted.
