Allow the sink underscore as placeholders for optional arguments.

[EskeRahn]

Let us assume we have some (odd) function with multiple optional parameters

bool MyWeirdFunction(out int res, int a = 1, int b = 12, int c = 123, int d = 1234) {
    res = a + b + c + d;
    if (res < 0) throw new ArgumentException("blah blah");
    return res != 0;
}

This can currently be called using the sink placeholder, e.g. with

_ = MyWeirdFunction(out int _, 1, c: 2);
_ = MyWeirdFunction(out int _, 1, d: 3);

But what about also allowing using the underscore as a placeholder for selecting the default for the parameter?

_ = MyWeirdFunction(out int _, 1, _, 2, _); // (last underscore superfluous, but added for readability)
_ = MyWeirdFunction(out int _, 1, _, _, 3);

if there are multiple calls to the same function next to each other it is easier to read, as you do not have to remember the names.

[foxesknow]

[EskeRahn]

My point on the sailed ship was that it is slightly confusing that in a switch syntax default is used as a keyword, literally referring to the default scenario.
But with the other usage, it is the default value of a type.

The following is quite counterintuitive IMHO:

        int foo = 10;
        int bar = 20;
        switch (SomeExperession(foo)) {
            case 1:
            case 2: bar = foo * 2; break;
            default: bar = default ; break; // Note 0 and NOT (SomeExperession(foo) as you would intuitively expect;
        }

It would have been better if they had used e.g. defaultof(T) (similar to typeof(T) and nameof(T)) or perhaps better Default<T> that with Implicit could be written Default
But they did not, so that ship has sailed...

[colejohnson66]

Previously, default(T) was required. A few years later, that restriction was removed. If you want to use default(T) still, you are free to do so.

And no, I would not "intuitively" expect bar = default; to mean bar = SomeExpression(foo); because default: is not binding anything in a switch statement. In C and every C-like language, I don't expect the default case to bind the switch "parameter" to a variable called default, so why would C# be any different?

You do have a point about reuse of keywords in C#, and reusing default does seem bad, in hindsight. But it was done when the type had to be specified. So your example of default: bar = default; would not compile unless it was written as default: bar = default(int);

Lastly, as I said, you can still use default(T) if you desire, but if you like Rust's style, you can also write your own Default<T>() function:

using System;
using System.Runtime.CompilerServices;
using static DefaultHelpers;

// can't also be named `Default` due to CS0542
public static class DefaultHelpers
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static T Default<T>() => default!; // or `default(T)!`
}

class Test
{
    public static void Main()
    {
        Console.WriteLine(Default<int>());
        Console.WriteLine(Default<string>() ?? "<null>");
    }
}

[EskeRahn]

I could have put it more harshly and said that if they had named the 'then new' functionality defaultof(T), and not misused ...erhm reused default for this, it could sensibly have been used (in similar functionality as in switch) as @foxesknow suggested. But indeed that ship has sailed, so not much point in continue talking about this, we just have to live with the odd reuse.

I would much prefer talking about the underscore suggestion that was supposed to be the topic here.

[CyrusNajmabadi]

it could sensibly have been used

One case is far more valuable and useful than the other. It's appropriate to me that we used default for the much more valuable case and not such a niche case as this :)

[EskeRahn]

Let me try again: The issue in this off-topic sub-discussion is not the function but the word.... defaultof would have been fine, and inline with nameof and typeof. But THE SHIP HAS SAILED, WE WILL HAVE TO LIVE WITH IT.

[TonyValenti]

The way I handle this in my code is to make all of my optional parameters nullable and default them to null. Then I coalesce them In the method body to their defaults.

This way default always gets me the default parameter value instead of the default type value. This approach is also nice because it allows me to implement default parameter values for complex types and classes

[EskeRahn]

I very often use this workaround too, especially to get non-static defaults, but strictly I see the magic value approach as a hack.

Note that

1. It requires that the magic-value ( null/default ) is not an acceptable value (almost always OK for params with defaults).
2. It obscures the actual default value for the caller, that VS present in the editor during typing.
3. It obscures to the code-reader that we are requesting the default value and not literally null
4. It adds extra code in the function/method, reducing code readability.

on 1) It usually works as null/default seldom is allowed for a parameter with a (different) default value. And in these rare cases overloads or a shadow method can do the needed magic.