Discussion: optional parameters after params

[alrz]

The main use case is to use caller info attributes with params.

static void M(params object[] args, [CallerLineNumber] int line = -1)

leading optional parameters would never match a positional argument.

[HaloFour]

How would the compiler disambiguate between an argument that belongs in the params array vs. those trailing optional arguments?

I guess one method would be to require that the following optional parameters be called as named arguments:

M(1, 2, 3);
// interpreted as
M(args: new object[] { 1, 2, 3 }, line: -1);

M(1, 2, line: 3);
// interpreted as
M(args: new object[] { 1, 2 }, line: 3);

[wdnijdam]

I like the params keyword to be removed completely to get rid of the ambiueness: #7843

[jnm2]

@HaloFour Hasn't an LDT member discussed allowing named parameters after params in this repo recently?

*Edit: sorry, meant specifically after the params keyword.

[HaloFour]

@jnm2

You mean allowing unnamed params after named params? That shipped with C# 7.2, but the compiler resolves the trailing unnamed arguments by position. That doesn't really work well with params as the compiler wouldn't have a good way of knowing when the params "argument" ended.

[djmarcus1]

I think that have a named parameter following the params is where the params stops.

For example:

void foo(params string[] varParms, string namedParm = "abc") {...}

An invocation:
foo("x", "y", namedParms: "z");

unambiguously (at least to me) that the varParms parameter should be assigned just the "x" and the "y").

In fact, this would even allow the following syntax:

void foo2(params string[] varParms = (list of string values), string namedParm = "abc");

The the only way to mark the end of a params list (on invocation) is to specify a named value).

This is backwards compatible (will not break any valid existing code).

The benefits:
Supports parameters past the params
Supports multiple params (as long as there is a named parameter as a separator)

It should even be possible to introduce a new syntax of ',,' as a marker for end of params (on invocation)

[jnm2]

No, I'm pretty sure that's not what I'm thinking of. I use that feature all the time.

[alrz]

@HaloFour

How would the compiler disambiguate between an argument that belongs in the params array vs. those trailing optional arguments?

in expanded form, overload resolution adds an "effective parameter" per each argument in argument list, so naturally the algorithm never reaches the optional parameters after params. that's why leading optional parameters would never match a positional argument. after we find the best candidate, all missing optional arguments will default to their default value (or caller info). if you do want to pass a value to leading optional parameters, you'll have to use named arguments for both params and leading optionals.

[HaloFour]

@jnm2

Oh sorry, read that wrong. You mean named parameters after a params parameter. Yes, I want to say I have heard that mentioned, but I don't think that was combined with the context of optional parameters.

void M(int a, params int[] b, int c) { }

M(1, 2, 3, c: 4);
// interpreted as
M(a: 1, b: new int[] { 2, 3 }, c: 4);

I think that makes sense.

But if c were optional the compiler would need to know if the final argument belongs to b or belongs to c. As I mention above this could be disambiguated by requiring that c be invoked by name.

void M(int a, params int b, int c = -1) { }

M(1, 2, 3, 4);
// interpreted as
M(a: 1, b: new int[] { 2, 3, 4 }, c: -1);

M(1, 2, 3, c: 4);
// interpreted as
M(a: 1, b: new int[] { 2, 3 }, c: 4);

I think that would work pretty well, honestly.

[alrz]

M(1, 2, 3, c: 4);

haven't thought of that. I think it could work, perhaps it makes sense to have non-optionals after params? I don't know how that could be useful though, but the above example can work for passing leading optionals without changing params args to array creation with a named argument.

[Thaina]

I think pattern-based ICollection and Tuple would solve this

I mean in my opinion I prefer to write Tuple as params instead of direct params

public void MultiParams(int i,IEnumerable<string> ss,IEnumerable<float> fs,bool option = false)
{
}

var vector3 = (0f,0f,0f);
MultiParams(0,("a","b","c"),vector3); // Tuple of same type will became ICollection<type> by compiler

[ChristopherHaws]

Another possible use case is when there is an optional CancellationToken, for example, it would be nice to have FindAsync(params object[] keyValues, CancellationToken token = default) for EF Core

dotnet/efcore#22667