Allow support for params IEnumerable<T> methods

Currently, C# only supports params T[], however it is rare that I actually need an array for my method. More often than not, I merely want iteration or to perform some sort of LINQ operators against the parameter. In fact, it is common for libraries to declare a version of the method that takes an IEnumerable<T> and a T[], and have the T[] version call the IEnumerable<T> variant.

The implementation detail could still be that an array is made at the call site and sent to the method, the benefit is to simply avoid having to create the extra overload.

[jaredpar]

If we are going to invest in a new params type I would like to see us invest in one that is more efficient than either T[] or IEnumerable<T> but equally inclusive.

Today low level APIs which expose a params method typically end up exposing several other non-params overloads in order to avoid call site allocation of the array for small numbers of arguments. It’s not uncommon at all to see the following:

WriteLine(params object[] args)
WriteLine(object arg)
WriteLine(object arg1, object arg2)

...

// The above pattern lets the following bind without the object[] allocation
WriteLine("dog");

Switching to IEnumerable<T> would not help here and would in fact make it works because it creates two allocations for a small number of arguments:

• The collection allocation at the call site
• The `IEnumerator<T> allocation in the caller

An idea we’ve sketched around a few times is a struct of the following nature:

struct Arguments<T> : IEnumerable<T>
{
  T _arg1; 
  T _arg2;
  IEnumerable<T> _enumerable;
  int _count;

  // struct based enumerator 
  // index which intelligently switches between T fields and enumerable
}

WriteLine(params Arguments<T> args)

The Arguments<T> struct represents a collection of arguments. In can be built off of individual arguments or a collection. In the case of a small number of individual arguments, which for many APIs is the predominant use case, it can do so allocation free. The compiler would be responsible for picking the best method of constructing Arguments<T> at the callsite.

[Pzixel]

@HaloFour

Any such method is already taking that risk if they don’t first check the IsReadOnly property. The IList interface makes no claim that the implementation is writable. Arrays have always implemented these interfaces.

And this is one of my least-favorite feature in BCL. Standad collection hierarchy is so ugly, and it seems that it will be as it is forever, becuase backward compatibility is the holy cow for Microsoft. It’s bizzare, that array implements IList, and half of methods throws NotAllowedException. Is it statically typed language or not?