Add wildcard to method/constructor arguments [Breaking change suggestion]

[julemand101]

(I could not find any issue similar to this. Also, I might be completely wrong and if that is the case, just close it :) )

As far as I understand the patterns proposal, we have a special meaning if a variable is called _ where we will not bind to any variable. But as far as I can read, it does not sound like this feature is going to be implemented in other areas like e.g. arguments to methods/constructors?

If not, then I would suggest the breaking change (maybe for Dart 3? Dart 4?) of making a _ in parameters an unbinding variable and make it so we cannot read this argument.

This should also make it possible to have multiple arguments named _ compare to the current behavior where _ is more like a suggestion from the programmer but data is still being assigned to the argument, which allow us to read the argument and prevents us from having multiple arguments named _ but are instead going to use __, ___ or similar.

As I see this, it would improve the usability of the language in general when patterns are introduced since I currently think it is kinda confusing that _ have a specific meaning in patterns but not outside of patterns.

I would expect a lot of people are already using _ to communicate an argument is not going to be used. But I do wonder how many are actually reading from an argument named _.

[Jetz72]

It does seem like it'd be nice to have a standard method of naming parameters you have no intention of using, which are only there because you're passing the function to something that expects a certain parameter list.

void errorCodePrinter(_, _, int errorCode) => print(errorCode); //Only cares about the third parameter; no name collision with the first two unused ones.
var thing = CallbackThing(
  errorHandler: printer //Expects a function that takes (Object, StackTrace, int).
);

I dunno if there's a good way to extend that idea syntax to named parameters. You'd have to name them anyway to specify which ones that you don't care about. Maybe just void handler({required int important, _}), with the underscore in the brackets indicating that any other named parameter is unused?

In general it'd be nice if you could specify a parameter that takes a function without caring too much what optional parameters that function takes. For instance, if you have a function like void addErrorHandler(void Function(Object error, StackTrace st)), you can't pass a function that just takes the error, because it wants a function that takes a stack trace as well. If you try changing that to make the stack trace part optional, e.g. void addErrorHandler(void Function(Object error, [StackTrace? st])), then now what it means is "either one or two parameters may be included but the handler still needs to be able to receive both, even though we don't care what it does with them". What I'd want is a way to specify the opposite - "the function will be called with two parameters but it can take either one or two, with the unused one disregarded". But as far as I'm aware the only way to allow that kind of flexibility is to just not specify parameters at all, accept any function, and check that it fits at runtime.

[lrhn]

I expect that we'll end up allowing (irrefutable) patterns in parameter position in a later language version. It's not part of the scope of the initial feature, but I don't see any technical reason to not get there eventually.
At that point, the irrefutable pattern _ will just work.

Should we just make _ as a parameter name (or any variable name) be unbinding from 3.0.0, in anticipation of this later change, and because it's what people use to mean "I don't care about the value" anyway? (And then they won't have to do (Object _, StackTrace __) to say that they don't care about the stack trace either.)

I'm all for it! :)

[julemand101]

I got hinted by @parlough that there seem to be already ongoing work on this feature request in the following document made by @munificent:
https://github.com/dart-lang/language/blob/master/working/wildcards/feature-specification.md

[munificent]

Heh, oops! I don't think I meant to commit that doc. :D

But, yes, I did start working on a proposal to make _ non-binding in all places. It's a breaking change, which makes it a little harder to prove that it's a good idea, but I do think it's worth doing. I should, uh, finish that proposal.

[munificent]

Update: I have a more complete proposal now, but it's not going to make it into 3.0.

[Mike278]

FWIW I tried out the new no_wildcard_variable_uses lint from dart-lang/sdk#51221 and it identified that I sometimes use the name _ for extremely short-lived variables - for example:

// "workaround" for https://github.com/dart-lang/language/issues/8
xs.map((_) => _.toString());

// "workaround" for https://github.com/dart-lang/language/issues/3001
users.map((_) {
  final (user, selected) = _;
  ...
})

[julemand101]

Dart 3.7 released with this change so I will close this issue.