Allow using discards as ignored optional parameters

[ghost]

Suppose we have this function:

void Foo(int x, int y = 10, bool z = true, string s = "Test")
        => Console.WriteLine($"{x}, {y}, {z}, {s}");

If we want to ignore y and z optional params, we have to use named arguments like this:
Foo(1, s: "something");

I slao suggest to allow us to use discards as placeholders of the messing arguments like this
Foo(1, _, _, "something");

[jnm2]

Naming the arguments brings clarity and I often do it without being forced to.

If C# was going to adopt this alternative approach which VB uses, would we want discards or just extra commas?

[ghost]

Extra commas in Vb.Net are difficilt to distinguish by human eye, especially when there are serveral blanck commas. "Disgards" is a good C# feature and it will be consistent to use rhem in all places where a variable or a parameter needs to be discarded.

[YairHalberstadt]

I think it is a sensible idea, and consistent with the language.

On the other hand, using named parameters is already possible, and better code style.

As such, we would be adding a feature which doesn't allow us to do anything we couldn't before, and encourages use of bad style. Hence this gets a 👎 from me.

[jnm2]

@MohammadHamdyGhanem Do you have a reason to downvote @YairHalberstadt’s point? It makes sense to me and your downvote makes it look like you aren't happy with Yair's point but can't argue with it.

[TheUnlocked]

This would be a breaking change:

int Factorial(int count = 2, int othervar = 0){
  int result = 1;
  for (int i = 1; i <= count; i++){
    result *= i;
  }
  return result;
}

// elsewhere:

int _ = 5;
Console.WriteLine(Factorial(_, 1)); // 2 or 120?

[YairHalberstadt]

@TheUnlocked
Anyone who uses _ as a variable name almost deserves whatever he gets, but seeing as the feature doesn't have any reason for it, a breaking change probably kills it.

[ghost]

@TheUnlocked
You brought up a serious point, which is really a surprize!.. See:

int _ = 5;
var t = (2, 4, 7);
int x, y;
(_, x, y) = t;
Console.WriteLine(_); // 2

We should propose that C# considers _ as a keyword and prevents using it as a name for variables, properties, methods, parameters.... etc.
The two samples you and me gave show the convulsion of using _ with two different meanings. Obviously, the _ variable beats the discard symbol.
Sure it will not break any old code, but it is still a bad design.
Thanks.

[svick]

@TheUnlocked

Not necessarily. _ already behaves differently depending on whether the identifier _ exists in the current scope:

{
    int _;
    _ = 42; // assignment to variable called _
}
{
    _ = 42; // discard
}

This means that in your example, count would be set to 5, to maintain backwards compatibility.

Maybe that would make it too confusing, but it wouldn't be a breaking change.

[theunrepentantgeek]

With this code, the author's intent is quite clear:

Foo(1, s: "something");

The alternative proposed here is quite opaque:

Foo(1, _, _, "something");

Only the original author of the code would know what this means without digging into the original definitions.

[ghost]

@theunrepentantgeek
You say that all function calls should be done by named arguments, even for non-optional params. This is not the practical case. You always see things like this
'DoSomething(1, "test", false);'
You only need a mouse hover to see rich info about the 'DoSomething function signature and possibly some info about its job and what every param does, if the author wrote some XML comments for this function.
So, lets take the named arguments benefits out of this discusssion. Practical practice shows that programmers don't prefere to use named arguments. Discards will make optional params feel normal. I don't mind allowing empty commas as will. Programmers preferences are different. The three ways are logical, and easy to understand by a glimpse, so they are all readable, and every programmer can choose what he prefers to write.

[theunrepentantgeek]

You say that all function calls should be done by named arguments, even for non-optional params.

No, I did not.

I'm saying that the existing syntax we already have not only works perfectly well but is decidedly superior to this proosal.

You only need a mouse hover to see rich info about the 'DoSomething function signature and possibly some info about its job and what every param

Not every C# developer uses Visual Studio. Some don't use any IDE at all (not even Visual Studio Code) - they use simple text editors, either by choice or because they don't have the option. Any suggested syntax change for C# needs to stand on it's own without requiring scaffolding provided by tool support.

[ghost]

@theunrepentantgeek
We have two ways to call normal parameters, so, why not optional parameters?
"Superior" is a point of view. If named arguments are superior as you say, so, they would have prevailed for decades, and there wouldn't any parameter call done without them. But they did not. I see them as a redundancy, and strange especially in C# where unreadable symbols are all over the code!
Besides, why does C# lab experiments with using empty commas for calling optional params? At least there are many requests for that.
Anyway, everyone has the right to use the syntax he prefers most.
Thanks.

[Austin-bryan]

So, lets take the named arguments benefits out of this discusssion

Um, what? You can't just say, "Let's take out the already existing feature that makes this feature pointless out of discussion." No, this feature already exists, and it makes yours pointless, so it's staying in discussion.

The three ways are logical, and easy to understand by a glimpse, so they are all readable, and every programmer can choose what he prefers to write.

No, three ways is actually a mess. I mean, how many ways are there to write properties? There's that many ways, not because the C# devs think writing code is a beautiful form of self expression, but because people kept getting tired of writing the longer boilerplate code. Python has their motto of there being one way, and only obvious way of doing something, and that's a good motto to follow to keep things simple. It would be very confusing to have all three ways.

Besides, which code is more clear in meaning:

AddAccount(_, _, _, _, _, _, _, 42);  
AddAccount(, , , , , , , 42);
AddAccount(age: 42);

You can see, the age: is the shortest, quickest to type (the first one is awkward to type and took longer than I thought) and most importantly, has the most meaning. What are all the other parameters? What does 42 mean? You would know if you were reading this on an IDE (which you're not).

so, why not optional parameters?

so, why not
that's you're argument? 🤣🤣

"Why not" is a very weak argument and shows you don't know what you're talking about. But if you really wanna know, I'll keep going.

C# features start off in the hole, by 100 points, and they have to earn 100 points to get out of it and to be taken seriously. That means that it has to be overwhelming positive to make it in.

We have two ways to call normal parameters, so, why not optional parameters?

Last time I checked...

CreateAccount("Jane", 42);   // Way #1
CreateAccount(age: 42);      // Way #2

Soo, since there are already 2 ways, we don't need your feature right?

"Superior" is a point of view.

Not really. So far, the examples have shown it to be shorter, and even if it's longer, it's much quicker to type, because it's 1., less awkward, and 2., has IDE support to add them.

If named arguments are superior as you say, so, there wouldn't any parameter call done without them.

Not true. Just because something is superior to something else, doesn't mean it's superior to all other things in the field. For example, a day old glass of milk smells better than a 7 day old glass of milk, that's pretty apparent. That does not mean that a day old glass of milk smells so good that everyone keeps one in their room and smells it every chance they can. No, it still smells bad, just not as bad. He never said that optional parameters are the best way to program, and they are the most superior form and there's nothing bad that could ever exist. It's just very helpful with the Foo(true, true, false, true, true, 7) methods. Also, they did not die out, but you're acting like they did.

I see them as a redundancy

They're not. Foo(true, 43) is lacking information, Foo(isMale: true, age: 43) adds information. Literally the oppposite of redundant. And remember, not everyone has cool IDE's, or is even using one. They could be reading it off StackOverflow.

and strange especially in C# where unreadable symbols are all over the code!

Not true. The majority of the code is named methods, variables, members, etc. Besides that, if it was really full of unreadable symbols, wouldn't it be important to add more readabilty, hence making optional parameters more important, not worsen the issue, by adding more unreadable symbols?

Anyway, everyone has the right to use the syntax he prefers most
They literally don't 🤣 Point to me where in the consititution it says we have that right. Can you imagine what an unlearnable mess C# would've been if the 3 MILLION C# programmers had their own say? It would be unteachable, and it would be insane to read someone else code, because my partner would be able to code syntax that could look more like Assembly, because it's their right.

The developers make the syntax, and if their nice, they'll add in the features we want to make it easier. That idea, is a complete privilege, not a right.

[ghost]

@willard720
Thanks for your detailed argument.
But in short:
1- Outside VS you can use named arguments. It will not disappear.
2- If the function has too many optional arguments, it is brief to use name arguments.
3- In most cases, there are 2 or 3 optional parameters, so it is better to use one or two discards:
DoSomething("Action", _, _, false)

Thanks

[svick]

@MohammadHamdyGhanem

Outside VS you can use named arguments. It will not disappear.

That's not how it works. If you use discarded arguments and then I view your code on GitHub or in Vim, I don't get a choice to use named arguments.

[jnm2]

@DavidArno I'm sorry, I don't find that example plausible. Assuming a non-terrible parameter name, how can argument position tell you more than naming the argument?

[DavidArno]

@jnm2,
Take the example,

Foo(1, 2, false, "a");

I have no named parameters; just positional ones. This is a common way to write code. I'm used to looking at positional parameters. When I then see,

Foo(1, _, _, "a");

I'm seeing the same positional parameters. Now two of them are using default values. I don't know what those default values are, but I know they are there; I know optional parameters are in play.

But when I see,

Foo(1, s:"a");

I've lost that positional parameter information. Without looking at the method signature, I can't tell that y and z are using default values, I just get a clue that optional parameters are likely involved as it's unusual to use just some named parameters in other scenarios, but I don't know how many are involved. So I feel the first case provides me with more information.

But as previously stated, I don't find optional parameters compelling in almost any circumstances. This feature doesn't offer enough benefit to overcome my objections to using optional parameters, so I still do not support it.

[jnm2]

But s is a terrible parameter name. Real parameter names tell you more than position does, and I use them even in default positions whenever it can enhance clarity.

Sometimes I'll even specify the default value of an optional parameter just so I can specify the parameter name.

[ghost]

@DavidArno
Optional parameters didn't exist until C# 4. If you have a method with 3 params and want to make overloads to allow use default values for two of them, then you will write 4 versions of this method. This gets worse as the no of params increases ( n params will neeed 2^n overlods). So, optional params are the solution for this.

Named arguments need a few more keystrokes to select the argument name from members list. But the worst case is when the argument name is too long, so the resulted code is not pleasant.
Foo(x, ignoreElementsWithOnlyWhiteSpaces: true);
So, I prefer:
Foo(x, _, true);

[DavidArno]

@MohammadHamdyGhanem,

Optional parameters didn't exist until C# 4. If you have a method with 3 params and want to make overloads to allow use default values for two of them, then you will write 4 versions of this method.

Indeed. And that to me waves a big red flag that something is wrong with the code. What's the use case for needing those default values? I've rarely come across examples of either overloads or optional parameters that I find convincingly solve a user need.

Directory.Delete is my favourite example of that problem. Two overloads with the same name, one with a boolean parameter, exist because optional parameters didn't exist when the method was created. If they had existed, we'd have had one method, with recursive being optional. But both ways are bad in my view and should have been two clearly named methods.

Wanting to supply default values to a method just feels wrong to me in most cases.

[jnm2]

Wanting to supply default values to a method just feels wrong to me in most cases.

You want to provide all five parameters to new StreamReader?

Directory.Delete is the same way, only less pronounced. Parameterizing options that are not commonly used is a great thing to do.

[ghost]

@jnm2

Sometimes I'll even specify the default value of an optional parameter just so I can specify the parameter name.

You can use named params with any non-optional param.

void Foo (int firstParam, int secondParam)
{
}

Foo(firstParam: 2, secondParam: 3);

By the way, there is an irritating behavior in the editor: When I select the named param name from the auto complete list (like firstParam:) it writes it without the colon, although it appears at the end of the name in the list! Does this worth reporting?

[DavidArno]

@jnm2,

StreamReader is a great example of what I'm talking about. I lost count how many constructors it has, but it has too many. In trying to help the developer it delivers a complete user-experience failure. I'd swap them for just two any day:

public StreamReader (System.IO.Stream stream);
 
public StreamReader (System.IO.Stream stream, 
                     System.Text.Encoding encoding, 
                     bool detectEncodingFromByteOrderMarks, 
                     int bufferSize, 
                     bool leaveOpen);

And if even more parameters were needed, or folk often only wanted to override the default for one of those parameters, I'd use the builder pattern to handle those options.

[jnm2]

@MohammadHamdyGhanem

You can use named params with any non-optional param.

Yes, that's what I do with many non-optional params. I even do it with optional params sometimes, which requires me to specify their default value.

@DavidArno

I'd swap them for just two any day:

No way! I so frequently need to specify leaveOpen that it is a huge pain to have to come up with a buffer size and specify detectEncodingFromByteOrderMarks. This is a great example of why optional parameters (or more overloads) are essential.

And besides, you'd be happy with two? That's still "wanting to supply default values to a method," and I don't think it ever feels wrong.

[jveselka]

I can imagine domains that have well specified paremeter order and using _ as default could be clearer.

1. In long chain of those calls so that they are aligned correctly contrary to named arguments.

public class Point
{
  public Point(int x, int y, int z) { ... }
  ...
  public Point WithCoordinates(int? x = null, int? y = null, int? z = null) { ... }
}
...
Point p = new Point(0,0,0);

p.WithCoordinates(5,_,_);
p.WithCoordinates(_,1,_);
p.WithCoordinates(7,_,7);
// lines above read better than lines bellow
p.WithCoordinates(x:5);
p.WithCoordinates(y:1);
p.WithCoordinates(x:7,z:7);

2. Methods that describe parameters in its name

public class ContextAndScope
{
  public ItemInScope(Context ctx = Context.Default, Scope scp = Scope.Default) { ... }
}
...
new ContextAndScope(_, myScope);
// reads better than
new ContextAndScope(scope: myScope);

This could indeed be preferable in minority of cases compared to named parameters, but I don't see why that should harm this proposal.

[CyrusNajmabadi]

By the way, there is an irritating behavior in the editor: When I select the named param name from the auto complete list (like firstParam:) it writes it without the colon, although it appears at the end of the name in the list! Does this worth reporting?

This behavior is intentional and by design.

[jnm2]

This behavior is intentional and by design.

It annoys me and the people I've worked with. Can you help this behavior make sense to me, or can I ask for a change?

[CyrusNajmabadi]

It annoys me and the people I've worked with. Can you help this behavior make sense to me, or can I ask for a change?

As with most things with suffixes in completion, the suffix is there for information purposes, but is not intended to be inserted so as not to screw with what you are typing. i.e. we put things like Prop = in the list to indicate 'named property', but hitting P<space>= gives you Prop = not Prop = =. Similarly, if you have a generic, and you type List< you get List<> not List<><.

[CyrusNajmabadi]

Finally, behavior like this is very difficult to change given that you will likely break the muscle memory built up by many users for how completion works. I'd prefer to not derail this convo. If you'd like to discuss more, we can do gitter, or we can do it in a new bug that is opened :)

[ghost]

I added a relevant proposal:
Allow discard ref and in params by boxing their values directly #1911