Idea: allow `||` instead of `|_|` in closures that ignore all parameters

[Nemo157]

With this “implicitly ignore every argument after the first N” pattern

Pretty sure writing a closure like |a, b, ..| (a, b) is explicitly ignoring every argument after the first N.

I’m in favour of this (.. in closure args) syntax and would support adding it to the language given some good examples of code that would be improved by it. It makes a lot of sense with the rest of the language. But I’m also probably never going to personally use it for the same reason @H2CO3 avoids _ in matches.

[withoutboats]

It’s not about open-mindedness though. The problem is not all new ideas; the problem is ideas that contradict some of Rust’s most important goals, safety and correctness, in the name of marginal “ergonomics”. (Incidentally, if there happen to be more such proposals than genuinely good ones is not a question of attitude, it’s a matter of fact.)

This is the close-mindedness I am finding so frustrating. You are presuming a particular subjective position (that a feature would “contradict some of Rust’s most important goals … in the name of marginal ‘ergonomics’”) has both moral and factual authority.

[H2CO3]

Yes, you’re right, I meant “explicitly” – I amended my reply accordingly. (It doesn’t matter much, though. Ignoring arguments in general without considering each use individually is still a dangerous act.)

[H2CO3]

That “subjective” position has been backed up by arguments and examples.

[MajorBreakfast]

I think that having |..| {} isn’t very dangerous. Changing the signature of a function is a breaking change and a library has to bump its major version to do it. Exactly the same is true from enums. For that reason I think that this is no more dangerous than a catch-all match arm or a match arm with a tuple pattern that contains ... @H2CO3 says that he avoids catch-all match arms because he wants to get notified by the compiler if an enum was changed. Same is true for |..| {}: If you don’t use it, it’s as if it doesn’t exist.

Here’s why I think |..| {} is an interesting idea:

• It’s explicit
• It’s self-explanatory
• It seems useful
• If you decide to not use it, it’s like it doesn’t exist

[H2CO3]

Changing the signature of a function is a breaking change and a library has to bump its major version to do it.

How does versioning help avoid bugs arising out of unintentionally ignoring an argument which should have been used? I don’t follow.

If you decide to not use it, it’s like it doesn’t exist

That’s only true as long as you only ever use code written by yourself, which is not realistic. It doesn’t help with the errors others make in their own code that you want to use.

[withoutboats]

I had a relevant experience recently in which I added a field to an enum variant. This variant already had 7 fields, and was matched over in a lot of places in the code base. Most of those places didn’t care about the field I was adding or several similar fields, because they are only relevant in a minority of cases. Really, the only existing code that cares about the field I added was the pretty printing module.

I had to change several locations where the variant was destructured (_, _, _, _, _, foo, _) to add another '_. There were many other locations, I saw by grepping, where the fields weren’t matched at all, and I fortunately didn’t have to edit it because it was just being matched ...

I don’t understand why closure arguments are different from destructuring? Why is it okay to have Pattern(..) but a bridge too far to have |..|? If one has been a part of Rust since before 1.0, how can the other contradict some of Rust’s most important goal?

(The code I was editing was adding async to the AST.)

[MajorBreakfast]

How does versioning help avoid bugs arising out of unintentionally ignoring an argument which should have been used? I don’t follow.

That’s only true as long as you only ever use code written by yourself, which is not realistic. It doesn’t help with the errors others make in their own code that you want to use.

Versioning helps because if you’re using the closure inside a function from a library and the library authors really respect semantic versioning, changes to the signature of that function can’t happen. (And if you change the signature of a private function, you can just update the places where you use the function with the callback)

I don’t understand why closure arguments are different from destructuring? Why is it okay to have Pattern(…) but a bridge too far to have |…|? If one has been a part of Rust since before 1.0, how can the other contradict some of Rust’s most important goal?

Looking at this from this perspective adding this feature would actually make the language more consistent with itself.

[ekuber]

I feel that the discussion is already at a point where an RFE could be written to add this for the |..| {} syntax. I oppose the || {} syntax to ignore checking the arguments for the same reasons already expressed above.

[MajorBreakfast]

@ekuber I think you mean “RFC” (request for comments) not “RFE” (request for enhancement), right? Just saying… probably the same thing anyway

[scottmcm]

That is, basically applying the slice pattern annotations to closure arguments.

I like the consistency of making function parameter patterns more like tuple patterns, and I think it’s consistent with a possible future extension (like in slice patterns) to variadic templates or tuple splatting or something.

[Centril]

@kamalmarhubi @tcr (or anyone else…)

Would you be willing to write up an RFC for allowing |..| and / or |x, ..|?

If you need any help in writing, you can ask for it here or join us at #rust-lang @ irc.mozilla.org.

[Centril]

Further summarizing arguments for the proposition of allowing |..| beyond what @MajorBreakfast wrote :

• It is still explicit since special syntax must be used to say “I don’t care about the rest”.
• It is readable; The meaning should be instantly recognizable for anyone who has seen .. elsewhere in patterns.
• It is more readable than the status quo; because the status quo forces the reader to see redundant noise to the semantic intent of the author.
• It is more ergonomic; because it removes noise, and the user doesn’t need to track the number of arguments and needs to write less when it applies.
• It is consistent with rest patterns in tuples, and structs
• It works with variadics
• it is opt-in (this is a minor point)

Arguments for the opposition (I am biased, so…):

• the exact structure of the arguments is less clear syntactically
• less information is given to type inference by not “pattern matching” on the exact number of arguments.

[H2CO3]

For fairness, you should boldface the opposing arguments, too. Furthermore, points 2-4 (“readable”, “more readable” and “removes noise”) are basically the same.

I feel we should summarize the other arguments against the feature too, as some of them point out how the pro arguments are not exactly obvious/unequivocal/uncontroversial:

• Although it’s “consistent” with rest patterns, its usage is as dangerous as the features it is similar to. The reason for this is that there will be no notice when a parameter is added which is potentially to be used for correct semantics.
• It’s not considered more readable by everyone. Some prefer to see each argument; typing and reading a _ isn’t a real issue.
• "opt-in" is only true if you don’t use anyone else’s code that relies on this feature. As long as you start using such code, you will be exposed to the potential bugs the feature may cause, even if you don’t use it yourself.

[MajorBreakfast]

@Centril

• Your “more readable” point (point 3) is the exactly the same as your point 4. Point 4 is phrased better
• I’m not sure what the second to last point means. Maybe I know it under another name. Is it the rest parameter?
• I don’t consider the last point, the “opt-in” point, minor. It means a lot for people who don’t want to use it.

@H2CO3

• All three points you’re listing make sense.
• The reason behind why it is dangerous should be added to your first point. “The compiler can’t detect when the number of parameters changes”

[Centril]

“opt-in” is only true if you don’t use anyone else’s code that relies on this feature.

Hence the minor point

I do think it is best that I not summarize the opposition too much; It is more genuine coming from someone who believes them more.

Furthermore, points 2-4 (“readable”, “more readable” and “removes noise”) are basically the same.

Readability is not the same as writing ergonomics (we should opt for the former, but it is nice when you get both added readability and writability).

@MajorBreakfast variadics: https://github.com/rust-lang/rfcs/pull/1935

[H2CO3]

Thanks, fair enough. I’ve added the reasoning to that point.

[MajorBreakfast]

Readability is not the same as writing ergonomics

This holds. However the reason you list in point 3 (“more readable”) appears again in point 4 (“ergonomic”). Meaning point 2 doesn’t have a unique reason at all. Also, I think the points are so similar that combining them to just “ergonomic” makes more sense.

About the whether the “opt-in” point is minor: If you want to state that it is minor, you need to provide a reason why you consider it minor. Edit: I see the reason in the other post. I mean you should add it

[Centril]

About the whether the “opt-in” point is minor: If you want to state that it is minor, you need to provide a reason why you consider it minor.

For the reasons @H2CO3 mentions. (or rather than “minor”, I should say: weak argument).

Also, I think the points are so similar that combining them to just “ergonomic” makes more sense.

I don’t agree here and I only ever use the word “ergonomic” for the writing side of things (reserving “readability” for the other case) and I want to avoid overloading it. But… whoever writes the RFC can decide how they want to frame the motivation; But I think you and I basically agree on the substantive issues on the feature itself beyond phrasing a motivation

EDIT: let’s not get bogged down in meta too much ^,-

[MajorBreakfast]

But I think you and I basically agree on the substantive issues on the feature itself beyond phrasing a motivatio

Yes we do. And we both like it. And it’s why I’d like to make a good case for it: This means each argument needs to be based on unique reasons. Otherwise the reader asks him-/herself “Didn’t I just read that?” and that’s no good.