Allow multiple params being specified

[Pzixel]

In C# we have currently a rule A params parameter must be the last parameter in a formal parameter list. I think it's too severe because it limits several cases even in standard library.

For example, string.Split method is declared like:
public string[] Split(char[] separator, StringSplitOptions options)

But it could be much more useful if it's declared like:
public string[] Split(params char[] separator, StringSplitOptions options)

But here we encounter with a problem that params cannot be non-last argument.

Proposal

Allow multiple params and params as non-last argument until they can be treated ambiguously, e.g.

string[] Split(params char[] separator, StringSplitOptions options); // allowed
string[] Split(params char[] separator, params int[] indicies); // allowed
string[] Split(params object[] separator, StringSplitOptions options); // disallowed, StringSplitOptions can be converted to object
string[] Split(params object[] separator, params int[] indicies); // disallowed, int can be converted to object
string[] Split(params int[] separator, params object[] indicies); // disallowed, int can be converted to object

[jnm2]

I'm not yet a fan of the double-params, but would be a fan big-time of unambiguous ending parameters following the params.

[aluanhaddad]

I sort of feel like the string.Split APIs are awkwardly shaped and that if separator were the last argument it would not be an issue.

Nonetheless, I feel your pain and ended up writing

using static System.StringSplitOptions;

static string[] SplitRemoveEmpty(this string value, char seperator, params char[] seperators) =>
    value.Split(seperators.Prepend(seperator).ToArray(), RemoveEmptyEntries);

static string[] SplitRemoveEmpty(this string value, string seperator, params string[] seperators) =>
    value.Split(seperators.Prepend(seperator).ToArray(), RemoveEmptyEntries);

a long time ago.

[alrz]

@aluanhaddad

That might make a good API proposal for corefx. Allocating an array for the most common case of Split where there is a single char isn't sensible.

[aluanhaddad]

@alrz you're absolutely right, those implementations are suboptimal. Thanks for the suggestion about making a corefx proposal, I may well now do just that.

[Pzixel]

@aluanhaddad good idea. However, I think there are some scenarios like:
var numbers = "1 2 3".Split(' ', '\t', StringSplitOptions.RemoveEmptyEntries);
and it still unambiguous and useful. We can wrap it in the method, add new overloads to BCL, but I think we still have cases that can't be covered so.