Discard parameters in method definition

[copygirl]

Proposal

My proposal is for the language to allow the use the discard syntax in method definitions. That is, naming multiple parameters _ .
This is already possible when defining lambdas, so I feel this is just an extension of that.

When a single parameter is named _, the behavior should stay the same as previous C# versions, and allow referring to the parameter by name.

When multiple discard parameters with name _ are used, an error should be generated if one were to attempt to refer to them.

Use-case 1

I have written a sort of DSL for my game engine which uses a source generator to analyze methods and their signature, and generates some additional code that actually defines and executes a query which will interact with a C library. I have chosen unused parameters to represent terms in this query which never hold any meaningful value.

Here is one such method:

public static void LoadMeshWhenDefined(Entity entity, Has<Mesh> _1, Not<MeshHandle> _2) { ... }

This will query every entity in the game that has a Mesh set, but does not yet have a MeshHandle, which is created when uploading the mesh to the graphics card, which is exactly what this method will do. It is a simplified example, but this will occur many times in my code.

Now as you can see I have two parameters in this method that I don't actually end up using, hence the naming _1 and _2.

With this change in place, I would be allowed to write the following, instead:

public static void LoadMeshWhenDefined(Entity entity, Has<Mesh> _, Not<MeshHandle> _) { ... }

Use-case 2

In some cases, a method may take a delegate argument such as Action<A, B, C> (or a proper delegate type with named parameters). A method passed to this other method might not need to make use of multiple of the given parameters, and as such it could use the discard syntax for them.

void Tab(string name, Action<Entity, History?, Entity?> contentMethod) { ... }
Tab("Components", ComponentsTab);
Tab("References", ReferencesTab);
Tab("Documentation", DocumentationTab);

private void DocumentationTab(Entity _1, History? _2, Entity? selected) { ... }
// could instead be written as
private void DocumentationTab(Entity _, History? _, Entity? selected) { ... }

[iam3yal]

@copygirl Can't you overload these methods? so it would look something like this:

void Tab(string name, Action<Entity, History?, Entity?> contentMethod)
{
    // ...
}

void Tab(string name, Action<Entity?> contentMethod)
    => Tab(name, (_, _, selected) => contentMethod(selected));

Independently to your request I feel like repeating yourself over and over by discarding isn't as pleasant experience as opposed to define precisely what you need once.

Just to clarify I understand what you're asking but looking at methods that their parameters was discarded is odd and I'm not sure how it's going to work with overload resolution but it seems to have things backwards in a way, instead of defining what you need as in my example with this proposal certain methods wouldn't have usable parameters similar to anonymous methods and lambada expressions only there it's local and make sense.

[copygirl]

I picked the examples I have because I happened to have run into them myself. In the first use-case, due to how I decided to write this "DSL", I believe there is no appropriate "workaround" - besides giving the parameters I don't need the actual values of unique names, of course.

In the second use-case, there's likely a dozen of other ways I could've written the code differently that avoids the need for this feature, but I wanted to showcase another potential use in a more "normal" coding context. In my particular case, I only have a single method that doesn't need these additional parameters, so creating an overload just for it seems overkill, at least to me. Or I could have different methods that all have different needs for the provided parameters. (Again, I know I can solve this, for example by throwing all the parameters into a type instead and passing that.)

I'm unsure what you are referring to with "not sure how it's going to work with overload resolution", unless you meant the previous point.

I was just thinking this might be a tiny usability feature that could be useful in some edge-cases, and it would mirror an existing feature.

[iam3yal]

there's likely a dozen of other ways I could've written the code differently that avoids the need for this feature

Well, it's probably much better and more reasonable to write the code differently then.

so creating an overload just for it seems overkill, at least to me

I was just thinking this might be a tiny usability feature that could be useful in some edge-cases

So you think that introducing an overload that not only solves the problem but it's probably more idiomatic and readable and available today is overall but introducing a language feature just because (in your words) it could be useful in some edge-cases really justifies it? I'm not trying to annoy you by any means but introducing new language features up to the smallest syntactic feature is quite expensive but who knows the LDT might agree with you, I'm just stating my opinion here based on my experience. 😄

[copygirl]

Couldn't one have made the same argument for lambda discards? Yet it's a feature we now have. It just isn't valid to use in the context of regular method definitions. To be clear I think this is a relatively tiny and insignificant feature but I came across it and felt like I wanted to put it out there. The cost of implementing this change is likely much higher than the resulting benefit.

[iam3yal]

@copygirl

Couldn't one have made the same argument for lambda discards?

Sure! but there are few differences and are as followed:

1. It's localized to a certain scope.
2. It doesn't appear in the intellisense.
3. It exists today because the LDT thought it makes sense to have it for lambda expressions and anonymous methods but the same arguments might not hold for methods.

o be clear I think this is a relatively tiny and insignificant feature but I came across it and felt like I wanted to put it out there.

That's great! and there is absolutely nothing wrong about it.

I'm just a person here who shares his opinion. 😄

[TahirAhmadov]

I think this can be useful when implementing interfaces or overriding virtual methods.

[ken-sprague]

I think consistency is the most valuable aspect of this proposal. C# 12 can use multiple parameter discards in lambdas, like event handlers:

button.Click += (_, _) => { ... };

and can use multiple discards with tuples:

var (_, _, _, pop1, _, pop2) = QueryCityDataForYears("Chicago", 1960, 2010);

so not being able to have multiple parameter discards in a method declaration feels inconsistent to me:

// This is OK in C# 12.
private void OnButtonClick(object _, EventArgs e) { ... }

// This is an error in C# 12, would be more consistent if the language allowed it.
private void OnButtonClick(object _, EventArgs _) { ... }

[HaloFour]

IMO it's just not worth it. Names are cheap, and ultimately the compiler would have to invent one anyway as it's unlikely that much tooling was designed to support unnamed parameters. Given that parameter names are a part of the contract of a method (and changing them can cause source breaking changes), whether or not you're using them, it seems to me that you should still name them.

[HaloFour]

Those are implementation details buried in an unspeakable type, not a part of a contract of an exposed type.

[copygirl]

What issues do you foresee getting in the way of this change? Is there a problem if the compiler really did just keep the name _ as for multiple discard parameters, instead of as you suggested, invent one? And tooling needs to keep updating to support newer language features already, doesn't it?

[HaloFour]

I don't think any of my concerns are insurmountable, but they increase the risk and effort that would be required. That needs to be weighed against the benefits of the proposal, which, in my opinion, are vanishingly small. Personally, I don't like the idea of exposing a parameter as unnamed, regardless of whether the body of the method intends to use it.

[theunrepentantgeek]

What issues do you foresee getting in the way of this change? I

It's not really about the issues getting in the way - every issue can be overcome, if there is sufficient value in doing so.

Eric Gunnerson's famous blog post Minus 100 points is very relevant:

Every feature starts out in the hole by 100 points, which means that it has to have a significant net positive effect on the overall package for it to make it into the language.

That blog post might date from 2004, but it's still relevant today.

[copygirl]

As I said in the other reply chain, I'm well aware it's likely not worth the development time for such an insignificant change.

I am however still curious about specific issues that could get in the way of implementing this.

[DavidArno]

This topic came up when discards were first discussed and it puzzled me why it was skipped even then. At the time, I felt the compelling use case was event handlers. An event handler has to fulfil a method signature contract, but all too often (it wouldn't surprise me if it weren't in the overwhelming majority of cases), those parameters are not used in the handler's code:

private void OnMonitoredFileChange(object sender, FileSystemEventArgs e)
{
    // code that never uses sender or e
}

I disagree that "names are cheap". Naming things is hard; this is a very well established fact of programming. In addition, names convey meaning, often confusingly, but they convey meaning. So expressing it as:

private void OnMonitoredFileChange(object _, FileSystemEventArgs _)
{
    // ...
}

instantly clarifies the meaning of those parameters: they are needed for a contract, but they aren't used.

I think it a nonsense to use the -100 points argument here. That applied to the concept of discards themselves. They were felt compelling enough to implement them: to allow their use in assignments, discards, patterns, for lambda parameters ... everywhere that you'd have a need for a discard at times, with the sole exception of method parameters. I don't know why the language team chose to not allow discards for method parameters. It might even be the case that they didn't choose; they simply overlooked it until it was too late and everyone had moved on to new features.
Edit to this: @ufcpp links to the language team's reasons below: "The fundamental limitation is that parameter names for methods and local functions are always public surface area to the caller".

It's like having a small stone in your boot. It's an irritation, but is it irritating enough to justify stopping, unlacing the boot, discarding the stone and relacing the boot? Probably not. Not being able to use discards for method parameters will just remain one of those annoying functionality inconsistencies that all apps, even compilers, accrue over time.

[DavidArno]

@eyalalonn,

Sure, there is the power of convention here:

sender is the thing behind the event. It's an object as the event handler convention predates generics, but you'll likely know the sender anyway as a 1:1 mapping of item/event and event handler is the norm.
e holds extra data specific to the event. You'll not need it 99% of the time, but it's there for that 1%

The signature is well understood. And is summarily ignored almost all the time. In fact the only time it's likely to trip up a developer is if it's not named that way. It's far from good naming, but it's easy and it's idiomatic. This is of course the downside to the work-around I mention above: using a lambda to enable the handler method to only have the parameters it needs results in better naming, but ironically may result in code that's harder to read for some developers.

[aemarco]

@ufcpp links to the language team's reasons below: "The fundamental limitation is that parameter names for methods and local functions are always public surface area to the caller".

I don´t see any concerning thing here. Is the caller not allowed to know, that this parameter is not used ??
--> If it´s because the parameter is defined in a Interface, the caller see´s the parameters name of the interface ?!
--> If the concrete type is used, I as a caller am pleased to know a certain parameter isn´t used.
Scrolled enough through foreign code to find for what a parameter is used... only to find out, that it isn´t used at all.

[HaloFour]

Is the caller not allowed to know, that this parameter is not used ??

I would definitely argue that it's an implementation detail that the caller shouldn't know nor care about.

Scrolled enough through foreign code to find for what a parameter is used... only to find out, that it isn´t used at all.

And what would happen if you made an assumption based on that only to find out that the next minor release did care a great deal about that parameter?

[aemarco]

@HaloFour
"And what would happen if you made an assumption based on that only to find out that the next minor release did care a great deal about that parameter?"

Fair point. In my opinion this depends a lot on the context.
Only because it´s discarded does not mean that you don´t need to pass something there.... and you can´t pass a null (if the parameter isn´t nullable). The method signature still demands that parameter!
Heck... you even can use that the other way around. In an anyway breaking change update, introducing that parameter (discarded), knowing that it will be needed for adding a feature down the road without "again" breaking stuff.

[seppo498573908457]

If it´s because the parameter is defined in a Interface, the caller see´s the parameters name of the interface ?!

This is my point in my earlier post. The only good reason for unused parameter to exist is too satisfy a contract (interface, event handler, virtual/override). If method is used through a contract, the contract will define the signature. If used directly, it falls down to implementation detail and that should allow "discarded" parameter names. If a method satisfies a contract, it's most probably used only through that contract.

Let's think of a scenario: event handlers in Windows Forms, specifically button click handler. These are quite common. Usually you don't need neither of the events two parameters and there is absolutely no harm in discarding them. If you need to call the event handler specifically, you would need to fabricate meaningful sender and eventArgs, pass in nulls or refactor the functionality to a new method and call it from all places. In all cases the parameters defined by the event handler would go unused and nobody cares.

[ufcpp]

See

csharplang/meetings/2019/LDM-2019-10-28.md

Lines 30 to 34 in 6ea8ab1

	For discards in local functions and method parameter lists, the cost/value ratio is not nearly as
	clear. The fundamental limitation is that parameter names for methods and local functions are
	always public surface area to the caller. We find the cost in complexity in resolving these
	questions higher than the feature is currently worth. If we find that it becomes a highly desired
	feature later, we would reconsider this decision.

[DavidArno]

Your ability to remember this stuff - or to know how to search for it - never ceases to amaze me, ufcpp 💯

[ufcpp]

Indeed, it may be easy to find it only because I have confidence that I have seen this topic before. However, the search terms themselves are very simple: "discard parameter regular".

[seppo498573908457]

I wrote a post and came to post it here, but found this discussion. I'll copy here what I would have posted. I think this feature would be as beneficial as any other discard feature.

There is a feature to discard out parameters etc and also code hints for them. But there is no feature the other way around. If a function or method has unused parameters, it will generate an IDE0060 remove unused parameter (parameter b in example below, in DiscardTestClass.TypicalMethod), except if that parameter is part of an overridden method (DiscardTestClass.MyOverridable), event delegate or interface implementation signature (DiscardTestClass.MyMethod). Currently, if I were to rename multiple unused parameters to _, it would generate a CS0100 parameter name is duplicate (DiscardTestClass.MyErronousMethod).

interface IDiscardTestInterface
{
    bool MyMethod(int a, string b);
}
class DiscardTestBase
{
    protected virtual bool MyOverridable(int a, string b) => a > 5 && b.Length < 10;
}
class DiscardTestClass : DiscardTestBase, IDiscardTestInterface
{
    public bool TypicalMethod(int a, string b) => a > 6;
    protected override bool MyOverridable(int a, string b) => a > 10;
    public bool MyMethod(int a, string b) => a < 5;
    public virtual bool MyErronousMethod(int _, string _) => false; // CS0100
}

Suggestion: Allow discarding parameters by naming them as underscore to denote intentionally unused parameters in at least virtual, override and interface implementation signatures and also event delegates if possible.

If someone is using underscore intentionally as a parameter name, use of such variable should produce an error (possibly breaking change). I would guess that any existing cases are for discarding purposes just as described above.

[jb-bcl]

When a single parameter is named _, the behavior should stay the same as previous C# versions, and allow referring to the parameter by name.

I understand that there's good reason for keeping this the same - backwards compatibility. That said, since C# is no longer fully opposed to breaking changes, my personal preference and an option to consider might be treating anything named _ as discarded if this proposal is ever implemented. Here's the reason:

Preventing the use of discard assignment

void SomeMethod(bool _)
{
    // ...
    _ = SomeOtherMethod_ReturnTypeIsNotBool(); // CS0029
    SomeOtherMethod_ReturnTypeIsNotBool(); // CA1806
    // ...
}

Assuming that SomeOtherMethod_ReturnTypeIsNotBool isn't named entirely stupidly, this is a compiler error (CS0029). _ is of type bool, and we can't assign the return type of our method to that. In other words, it's not possible to discard the return value of our method, resulting in an inspection from CA1806 when we call it.

"False positive" use of discard assignment

Let's say we're subscribing to an event with a sender and some EventArgs. We don't care about the sender.

void OnEvent(object _, EventArgs e)

Per the original specification here, _ is a parameter of type object, and can be assigned to. Since the type of _ is object, we can assign anything to it. At a glance, it may look like someone's used the discard operator, but in fact, they've changed the sender - and, someone correct me if I'm wrong, but I believe that if the event is routed, this could mean events further down the line will have a false idea of the sender.

Summary

In short, I feel like it would be better to treat anything named _ as discarded, both for code cleanliness and to prevent mistakes where users falsely believe they've used discard assignment where they've in fact assigned to a variable.

[CyrusNajmabadi]

That said, since C# is no longer fully opposed to breaking changes,

We're basically not opposed, as long as the value is very high, and very few people and code cases are truly impacted in the wild. Unfortunately, people using _ as an identifier is normal and appears a fair amount in code bases. So this would be pretty painful in practice to a lot more people than we likely would be comfortable with.

[copygirl]

Regarding '"False positive" use of discard assignment', your assumption is incorrect. A reference type can be reassigned without affecting it. The problem would only occur for a ref parameter such as ref object _. (So it's still possible, just much less likely to come across in the wild.)

object value = 5;
SomeFunction(value); // reassigning won't affect value
Console.WriteLine(value); // will always print 5

(I'm sure with some unsafe code you could probably change the value inside the wrapped int object, but that's beside the point.)

[jaredpar]

In short, I feel like it would be better to treat anything named _ as discarded,
Unfortunately, people using _ as an identifier is normal and appears a fair amount in code bases.

It's very easy to demonstrate how prevalent this is by just doing a github search for the pattern _ => _.. The level of buy into that pattern is so high I think it's extremely unlikely we'd ever take a full break here.