Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upEmit warnings on parameter list in closures after { #27300
Comments
This comment has been minimized.
This comment has been minimized.
Xirdus
commented
Jul 26, 2015
|
I don't think we should make custom-tailored error messages for people trying to write code in their favorite language and then compile it with rustc. Just like we don't issue any special warning on assigning result of assignment to a variable, we shouldn't issue a warning when someone tries to write Ruby lambdas in Rust. People should learn that even if something looks similar, it doesn't mean that it works the same as in their old language. |
This comment has been minimized.
This comment has been minimized.
|
@Xirdus nobody said anything about custom tailored messages and the problem is that the code from Ruby does compile in the first place (see the very first code snippet). Changing that, however, would be a breaking change, so instead, I proposed the solution as a warning that actually makes sense! Maybe don't even change the warning, just make a "note: did you mean |
This comment has been minimized.
This comment has been minimized.
Just to clarify (for you and anyone who may stumble over this syntax in the future and find this issue): let p = Some(45).and_then({|x|
Some(x * 2)
});is the same as let p = Some(45).and_then({
// This is a block with only one expression.
// It returns this expression (the closure):
|x| { Some(x * 2) } // braces optional
});This is totally legitimate and should compile. Your other example let p = Some(45).and_then({|x|
println!("doubling {}", x);
Some(x * 2)
})could be written as let p = Some(45).and_then({
|x| { println!("doubling {}", x) }; // braces optional
Some(x * 2) // returns `Some(i32)`
})I understand why rustc's error message is confusing. A solution would be to reformat your code shown in the error and annotating the blocks. (This might make stuff more confusing in other cases, though!) |
This comment has been minimized.
This comment has been minimized.
|
@killercup thanks for the response! So you're saying we need |
This comment has been minimized.
This comment has been minimized.
|
@muja you can already use https://github.com/nrc/rustfmt! (That isn't integrated into the compiler, though, so the error snippets won't get pretty by themselves.) |
This comment has been minimized.
This comment has been minimized.
stevenblenkinsop
commented
Jul 26, 2015
|
In the first case, there could plausibly be a hint if you try to use a closure parameter in a subsequent statement, such as
For the second case, plausibly, when the expression for a closure isn't a block, you could have a hint:
|
This comment has been minimized.
This comment has been minimized.
|
Note that if the unbound variable error hadn't arisen (e.g. because There are a couple of different ways rustc could generate a more helpful error message here. If an unbound variable is found in an identifier in the same scope as a previous closure statement that uses that identifier, it could point out that the statement is not inside the closure. If a closure is the first statement of a block and not bound with a
This is off-topic, but it would be undoubtedly more helpful if a user wrote e.g. |
steveklabnik
added
the
A-diagnostics
label
Jul 29, 2015
brson
added
C-enhancement
T-compiler
P-low
labels
Jan 26, 2017
steveklabnik
removed
the
T-compiler
label
Mar 9, 2017
estebank
referenced this issue
Jan 26, 2018
Closed
Detect possibly non-Rust closure syntax during parse #47763
This comment has been minimized.
This comment has been minimized.
|
Given #47763, overly verbose, but educative output actually pointing at the problem:
|
muja commentedJul 26, 2015
Reproducing steps
This code compiles (and, in my opinion, it shouldn't):
While this doesn't:
Error message 1 (using x)
The error message is absolutely unintuitive and won't help anyone:
Playpen link
Error message 2 (not using x)
When the last expression does not use a parameter from the list, the generated error message is even more frightening to newcomers (albeit in retrospect, this one makes more sense):
Playpen link
Proposed solution
Emit a warning when encountering this fallible syntax.
Anecdotic background
Having used a lot of Ruby, I had grown way accustomed to the
{ |x| x * 2 }syntax. Although I had seen the proper Rust syntax a couple of times, it never was emphasized and the significance never stuck. I spent 30+ minutes trying to figure out why a println! statement breaks the build, generating a random error message that has no obvious connections to the actual bug at hand. Only after inquiring the IRC channel did a solution unveil itself. It shouldn't happen.