csharplang/meetings/2022/LDM-2022-06-29.md

C# Language Design Meeting for June 29th, 2022

Agenda

• 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?

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.