Repository navigation
Closed
Labels
A-async-awaitArea: Async & AwaitArea: Async & AwaitA-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-suggestion-diagnosticsArea: Suggestions generated by the compiler applied by `cargo fix`Area: Suggestions generated by the compiler applied by `cargo fix`AsyncAwait-TriagedAsync-await issues that have been triaged during a working group meeting.Async-await issues that have been triaged during a working group meeting.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
Hi,
Let's consider following code:
fn foo() -> usize {
0
}
fn bar(i: usize) {
}
fn main() {
bar(foo);
}Right now it fails with the expected usize, found fn item message - I think it would be helpful if compiler bragged about missing parentheses when function's return type matches expected type:
fn main() {
bar(foo);
// ^^^ expected usize, found fn item
// hint: try invoking the function: foo()
}It may even help a little bit when dealing with async functions - recently I've written:
async fn foo() {
}
fn bar(f: impl Future<Output=()>) {
}
fn main() {
bar(foo);
}... and it took me a few minutes to notice that what I actually wanted was bar(foo()).
Reacted by eupn, phrohdoh, Esteban Kuber and Squirrel
Metadata
Metadata
Assignees
Labels
A-async-awaitArea: Async & AwaitArea: Async & AwaitA-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-suggestion-diagnosticsArea: Suggestions generated by the compiler applied by `cargo fix`Area: Suggestions generated by the compiler applied by `cargo fix`AsyncAwait-TriagedAsync-await issues that have been triaged during a working group meeting.Async-await issues that have been triaged during a working group meeting.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
cramertj commentedon Jul 29, 2019
@Centril why was this tagged async-await?
Centril commentedon Jul 29, 2019
cramertj commentedon Jul 30, 2019
I don't think that makes this an async/await issue in any way, though. 🤷♀️
gilescope commentedon Jul 31, 2019
It's a great suggestion either way. Going to take a crack at it if I may?
@rustbot claim
gilescope commentedon Aug 17, 2019
Move to close this as PR #63337 now merged in nightly fixes this:
gilescope commentedon Aug 17, 2019
@Centril thoughts?
Centril commentedon Aug 17, 2019
The message for async/await is still bad:
Leaving this up to @estebank
Patryk27 commentedon Aug 17, 2019
IMO the
{foo} defined herepart looks weird (why curly braces?) - how about:estebank commentedon Aug 19, 2019
@Patryk27 I feel like
fn foo() -> usizecould also work and be more natural. At the same time, I'd like to unify how we refer to functions and closures (currently[[email protected]:LL:CC]), and I feel that the braces style is would be suitable for them:fn(_) -> _ {file.rs:LL::CC}.Patryk27 commentedon Aug 20, 2019
@estebank Thanks, I understand - I'm not certain about curly braces in this position, since it changes their meaning though (from denoting block to denoting location, depending on whether it is part of code block or message) and thus, to me, they are kinda confusing.
IMO the
fn(_) -> _ [file.rs:LL:CC]construct could be more legible, since brackets are not usually set together with functions (contrary to curly braces), so they stand out more.estebank commentedon Aug 24, 2019
#63870:
😊
Rollup merge of rust-lang#63833 - estebank:suggest-closure-call, r=pe…