-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Guide: closures #16206
Guide: closures #16206
Conversation
imo you should mention explicitly that the point of the restriction that |
i'm also surprised that your example closure only infers the return type and not the argument type. I know it works in some contexts (like |
I was having a weird error with inference at first, so I left that out. |
|
||
Let's compare syntax. The two are pretty close: | ||
|
||
```{rust,ignore} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why ignore
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does fn let you put spaces after like that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
apparently it does
I learned about closures before they had the tutorial's current expanded state and found them very confusing (which led to it's current expanded state; I worked on the previous one and so I'm very interested in this one). So I wonder if this brief treatment will be enough. Having said that, I don't see any big problems in the current treatment. So I'm hoping someone unfamiliar with them will come along to detail any difficulties or lack of they have with this treatment. |
I'm going to wait to fix up this section until after unboxed closures land, since that should be soonish. |
Fixed up a bunch of these comments. After the doc meeting with @nikomatsakis and @brson yesterday, we decided to land this section as-is, without regard for unboxed closures, and when unboxed closures get here, we can update it to properly reflect whatever changes they bring. |
println!("The 5 plus 1 is {}.", add_one(5i)); | ||
``` | ||
|
||
We create a closure using the `|...| { ... }` syntax, and then we create a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the next closure revision:
Also, I believe it's idiomatic for short simple one-expression closures to just be written without the { ... }, e.g. |x: int| x * x - by @huonw
Kimundi posted here an explanation of the updated closures. This example from his work looks sorta like mixing of those types:
let mut counter = 0u;
let a = 128;
let counter_ref = &mut counter;
let by_mix = |b| if b > a { *counter_ref += 1; };
// Captures a and counter_ref as value
by_mix(64);
by_mix(256);
by_mix(1024);
assert!(counter == 2)
Specifically here it looks like a mixing of the no braces allowance and requiring it. It also looks a little like a pattern guard on a match:
let by_mix = |b| if b > a { *counter_ref += 1; };
I don't know if it's worth calling out an example like this in the future or not but I wanted to point it out in case it's worth it.
Fix some comments
No description provided.