[API Proposal]: Predefined `InlineArrayX<T>` types up to some X

[333fred]

Background and motivation

Today, Roslyn will emit anonymous inline array types when users call methods that take params ReadOnlySpan in params form, or when using collection expressions in some fashion. There can be a significant number of these types; for example, @jaredpar found that in Microsoft.AspNetCore.App, there are ~110 such types. In Microsoft.NetCore.app, there are ~136 such types. Most of these types are 5 elements or smaller, thus I'm only proposing up to InlineArray5. However, we may want to consider going further; dotnet/roslyn#74538 asks for Roslyn to emit calls to string.Concat(ReadOnlySpan<string>), which may push the numbers here up more. Note that Roslyn will continue to use the discrete string.Concat(string, string, ...) methods where possible, so if we only do up to 5, then the benefit to string.Concat may be minimal. I'll leave it to the BCL designers to decide what number is right, and Roslyn will take advantage of whatever is available.

API Proposal

namespace System.Runtime.CompilerServices;

[InlineArray(1)]
public struct InlineArray1<T>
{
    private T t;
}
[InlineArray(2)]
public struct InlineArray2<T>
{
    private T t;
}
[InlineArray(3)]
public struct InlineArray3<T>
{
    private T t;
}
[InlineArray(4)]
public struct InlineArray4<T>
{
    private T t;
}
[InlineArray(5)]
public struct InlineArray5<T>
{
    private T t;
}

API Usage

var finalString = string.Concat(str1, str2, str3, str4, str5); // The compiler uses InlineArray5<string> behind the scenes

Alternative Designs

No response

Risks

No response

[333fred]

/cc @stephentoub

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

[jaredpar]

Here is the histogram breakdown of usage:

Microsoft.NetCore.App

0:  (0)
1:  (0)
2: ***************************************************************** (65)
3: ******************************************** (44)
4: ************************* (25)
5: ** (2)
6:  (0)
7: * (1)
8: * (1)
9:  (0)
10:  (0)

Microsoft.AspNetCore.App

0:  (0)
1:  (0)
2: ********************************* (33)
3: ******************************** (32)
4: ******************************************* (43)
5: **** (4)
6: *** (3)
7: ** (2)
8:  (0)
9:  (0)
10: * (1)
11:  (0)
12: * (1)
13:  (0)

[stephentoub]

In the data Jared shared with me, the 95% cases were covered by 2, 3, and 4, and there were no occurrences with 1. As this is mainly a size optimization, I'd be inclined to start small and only add the types that have the biggest bang for the buck. We can always add more later as needed.

[stephentoub]

@333fred, how would the compiler decide what types are available to it to use? Is it based on a naming scheme? Anything that's generic and an InlineArray of the right size?

[hez2010]

Oh no... How about doing this for them all: #89730

[jaredpar]

... and there were no occurrences with 1.

In the case of a single element collection expression targeting Span<T> the compiler uses the Span<T>(ref T) constructor. That means the compiler can put a T local on the stack and use that for storage. May be missing a case but pretty sure this allows us to avoid a one element inline array whenever targeting .NET Core 7+.

[hamarb123]

I'd suspect that up to 16, and then a few powers of 2 after that should pretty much cover the vast majority of projects for all time, so that would be good. Not only for compiler emitted ones, but also for ones an advanced developer might write themselves (I certainly would switch to using these over ones I have defined myself where possible).

Would be good if we could add where T : allows ref struct as well, even though that part would not work from C# directly today, as these would ideally also be used in lowering [refStruct1, refStruct2] -> ReadOnlySpan<MyRefStructType> if and when that is supported.