Allow optional arguments in the middle of the argument list

[ekolis]

For instance:

public void DoStuff(int x, int y = 0, int z)
{
    // do stuff
}

To call it with a default value for y just put two commas in a row:

DoStuff(42, , 86);

Or maybe to be clearer use a discard:

DoStuff(42, _, 86);

[sharwell]

The main case where this would be interesting for me is having a combination of:

1. One or more optional parameters
2. A non-optional CancellationToken parameter
3. Having the CancellationToken parameter appear last

[HaloFour]

Looks like both the compiler and the tooling support consuming assemblies where a method has optional parameters followed by required parameters:

As you can see the compiler supports invoking those methods as long as the required parameters are explicitly specified, which requires using named arguments.

[sharwell]

@HaloFour That's fascinating.

@ekolis I'm curious: would your use case be completely covered if the language just allowed trailing required arguments? If we retained the requirement that optional parameters appear in sequence, with zero or more required parameters before and after, I think it would be easier to implement and use.

[ekolis]

@sharwell Trailing required arguments? Isn't that semantically identical to what I proposed? Or is there some subtle difference I'm missing?

edit: oh, you're saying all the required arguments have to come together, you can't do this:

public void DoStuff(int a, int b = 0, int c, int d = 42)

I would prefer there be no restrictions on the placement of arguments.

[CyrusNajmabadi]

@ekolis could you give some real examples of APIs where the above would be desirable both from an API production and consumption perspective? DoStucc(a, b, c, d) has no meaning and gives me no insight as to why this would actually be beneficial.

Thanks!

[tannergooding]

You can already achieve this today using [System.Runtime.InteropServices.OptionalAttribute] and [System.Runtime.InteropServices.DefaultParameterValue].

The C# compiler recognizes and correctly supports these attributes if manually specified (and emits them under the covers).

https://sharplab.io/#v2:C4LglgNgNAJiDUAfAAgBgATIIwDoBKArgHbBgC2ApjgJIkUBOA9gA4DKDAbmAMYUDOAbgCwAKGQBmTACZ0AYXQBvUehWZJyACzoAsgAowJdAA90AXnQBWAJSLlqgL52VTtZi0A5XQG0A8s1KMRACG0OgAIhQAZkEEEMAACkH0QZTADABqIQQUutYAuugGwMZQmFgYAJ42SiKq6I61qi4Sbug+ulYuNXV1elbCjT3onhUg6ABEQeP9Lg32QA=

[HaloFour]

@tannergooding

Interesting, so C# already supports consuming said assemblies and producing said assemblies through manually applying pseudo-attributes. Is there a reason C# doesn't permit optional parameter syntax in this situation?

[tannergooding]

@CyrusNajmabadi, there are a number of native interop APIs (such as in DirectX) where the optional parameters arent always trailing.

APIs such as TryParse(string, IFormatProvider, out T) is another (format provider is technically optional but we say out parameters go last).

That being said, I expect it is rare enough that the manual workaround is sufficient (it's what I do for the interop scenario right now).