Support + with ReadOnlySpan<char>

[stephentoub]

Now that the C# language will have first-class knowledge of spans, it'd be great if string concatenation (+) could support ReadOnlySpan<char>, e.g.

string s = ...;
string result = "prefix" + s.AsSpan(1);

would lower to the equivalent of:

string s = ...;
string result = string.Concat("prefix", s.AsSpan(1));

[colejohnson66]

Is this not possible in the BCL? "Just" add an operator overload. Or is string special?

[stephentoub]

There's no way to add such an overload today, e.g. you can't statically have an operator overload on ReadOnlySpan that applies only to ReadOnlySpan<char> and not other ReadOnlySpan<T>, and for it to be an operator overload on string it would need to involve a string, which would then mean that s.AsSpan(0, 1) + s.AsSpan(2) would not work. It will hopefully eventually be possible via extension operators, but that's not available yet. And even when it is, we'd still want it special-cased so that chains of such concatenations are lowered into a single string creation, e.g. that span1 + span2 + span3 becomes string.Concat(span1, span2, span3) rather than the equivalent of string.Concat(string.Concat(span1, span2), span3).

[TahirAhmadov]

If we were to wait for extensions and the + is added to (ReadOnly)Span<char>, wouldn't it be possible to optimize the nested Concats as a runtime optimization? Wouldn't that optimization be beneficial by itself?

[colejohnson66]

@stephentoub's point is that, with extensions/operator overloads, span1+span2+span3 would get lowered as op_add(op_add(span1, span2), span3). There's two allocations there. With strings, it gets lowered as string.Concat(str1, str2, str3) - only one allocation. If the compiler can special case ReadOnlySpan<char>.op_add like it does string.op_add, the JIT doesn't need any work.

[TahirAhmadov]

I understand that, but in other cases, the position is usually to let JIT optimize things like this, instead of special casing in the language. I'm just trying to understand why this situation is different. (Obviously if the wait for extension operators is unacceptable and the + on Span<char> is needed sooner, that's a perfectly valid explanation argument - I imagine others could argue that a special new language feature is too expensive to save a year or two of wait time.)
PS. The extra benefit is that for cases where Concat is called in a nested manner (for whatever reason), this optimization would improve that code's performance automatically as an added benefit.

[huoyaoyuan]

With interpolation now, is + really preferrable?

I'm not a big fan of + on strings, especially with other objects.

[CyrusNajmabadi]

I'm not a big fan of + on strings, especially with other objects.

This has been the idiom in C# since 1.0. It's a core part of how we want people to work with strings :)