Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
julemand101 opened this issue Dec 9, 2022 · 6 comments
Labels
feature Proposed language feature that solves one or more problems patterns Issues related to pattern matching.

Comments

@julemand101
Copy link

(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 _.

@julemand101 julemand101 added the feature Proposed language feature that solves one or more problems label Dec 9, 2022
@Jetz72
Copy link

Jetz72 commented Dec 9, 2022

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
Copy link
Member

lrhn commented Dec 9, 2022

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! :)

@lrhn lrhn added the patterns Issues related to pattern matching. label Dec 9, 2022
@julemand101
Copy link
Author

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
Copy link
Member

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 munificent added patterns-later and removed patterns Issues related to pattern matching. labels Apr 7, 2023
@munificent
Copy link
Member

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

@munificent munificent added patterns Issues related to pattern matching. and removed patterns-later labels Aug 28, 2023
@Mike278
Copy link

Mike278 commented Nov 21, 2023

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) = _;
  ...
})

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Proposed language feature that solves one or more problems patterns Issues related to pattern matching.
Projects
None yet
Development

No branches or pull requests

5 participants