How do params work in modern C#, and what changed with C# 13 params collections? Explain params arrays and their hidden allocations, params ReadOnlySpan<T>, params IEnumerable<T> and List<T>, how overload resolution chooses between them, the new BCL overloads in .NET 9, and API design guidance.

How I would answer this in an interview

params lets callers pass a variable number of arguments without building a collection themselves. Classic params T[] always allocates an array per call. C# 13 params collections allow params on spans and other collection types — notably params ReadOnlySpan<T>, which can put the arguments on the stack with no allocation. .NET 9 added span-based params overloads across the BCL, so existing code got faster just by recompiling. I'd cover hidden allocations, the new forms, overload resolution, and API guidance.

1. params arrays and their hidden allocations

public static string JoinTags(params string[] tags) => string.Join(",", tags);

JoinTags("a", "b", "c");   // compiler: JoinTags(new[] { "a", "b", "c" }) - allocates an array EVERY call
JoinTags();                 // compiler uses Array.Empty<string>() - no allocation
JoinTags(existingArray);    // passes the array directly - no allocation
JoinTags(null);             // passes a NULL array (not an array containing null)!

In hot paths (logging, string building, Task.WhenAll(t1, t2), Path.Combine(a, b, c)), these per-call arrays add GC pressure. With params object[], value-type arguments are also boxed.

2. params ReadOnlySpan<T> (C# 13)

public static int Sum(params ReadOnlySpan<int> values)
{
    int total = 0;
    foreach (var v in values) total += v;
    return total;
}

Sum(1, 2, 3);          // arguments placed in a stack-allocated inline array - NO heap allocation
Sum([1, 2, 3]);         // collection expression also works
Sum(array);             // arrays convert to ReadOnlySpan<int>

The compiler uses an [InlineArray] buffer on the stack (or static data for constants) and passes a span over it. The method can't store the span (it's a ref struct), so it's safe.

3. params IEnumerable<T>, List<T> and other collections

C# 13 allows params on any type that supports collection expressions:

• params Span<T> / params ReadOnlySpan<T>.
• params IEnumerable<T>, IReadOnlyCollection<T>, IReadOnlyList<T>, ICollection<T>, IList<T> — the compiler picks an implementation (often an array or List<T>).
• params List<T>, params HashSet<T>, params ImmutableArray<T>, custom types with [CollectionBuilder].

This is mostly about flexibility (e.g. accepting a List<T> or IEnumerable<T> directly and individual arguments), while ReadOnlySpan<T> is about performance.

4. How overload resolution chooses

When multiple params overloads exist (e.g. a library adds params ReadOnlySpan<T> next to params T[]):

• For expanded form calls (M(1, 2, 3)), C# 13 prefers params ReadOnlySpan<T> over params T[] — so recompiling picks the allocation-free overload.
• ReadOnlySpan<T> is generally preferred over Span<T>, and span over array, which is better than IEnumerable<T> ("better conversion" rules for collection expressions).
• Non-params overloads with exact arity (e.g. M(T a, T b)) still win over params.
• Library authors can use [OverloadResolutionPriority] (C# 13) to steer resolution and avoid ambiguities.
• Passing an array to methods with both overloads binds to the array overload (identity conversion) unless priorities say otherwise.

5. New BCL overloads in .NET 9

.NET 9 added params ReadOnlySpan<T> overloads to many APIs, including string.Join, string.Concat, string.Format-related helpers, Path.Combine/Path.Join, Task.WhenAll/WhenAny, CancellationTokenSource.CreateLinkedTokenSource, StringBuilder.AppendJoin, Console.WriteLine formatting overloads, TextWriter.Write, ImmutableArray.Create and more. Code like Path.Combine(root, folder, file) or Task.WhenAll(t1, t2, t3) now avoids the array allocation after recompiling with C# 13+.

6. API design guidance

• For new hot-path APIs taking a variable number of inputs: use params ReadOnlySpan<T> (the method can only read and not store them — usually what you want).
• If you need to store the values, use params T[] (the caller's array may be passed directly; copy it if you need immutability) or a collection type.
• Keep fixed-arity overloads for the most common counts if they enable important optimisations (e.g. Log(string, object)).
• Avoid params object[] for value-heavy APIs (boxing) — use generic overloads or interpolated string handlers.
• When adding span overloads to an existing library, check for ambiguities and use OverloadResolutionPriority.
• Validate null for params T[] (callers can pass null explicitly); spans can't be null (but can be empty).

7. A production example

A high-throughput API used Path.Combine(a, b, c), string.Concat(x, y, z, w) and Task.WhenAll(t1, t2) in per-request code, plus our own Metrics.Tag(params KeyValuePair<string, object>[] tags) helper. Upgrading to .NET 9/C# 13 removed the BCL array allocations automatically. We changed our helper to params ReadOnlySpan<KeyValuePair<string, object?>> (and later to TagList), which cut per-request allocations in the metrics path to zero.