Thought of this while reading https://fasterthanli.me/articles/i-am-a-java-csharp-c-or-cplusplus-dev-time-to-do-some-rust (thank you @fasterthanlime !). Currently putting a function in a struct definition is a syntax error without much hint of what went wrong (playground):
struct S {
field: usize,
fn do_something() {
}
}
error: expected identifier, found keyword `fn`
--> src/lib.rs:4:5
|
4 | fn do_something() {
| ^^ expected identifier, found keyword
error: expected `:`, found `do_something`
--> src/lib.rs:4:8
|
4 | fn do_something() {
| ^^^^^^^^^^^^ expected `:`
error: aborting due to 2 previous errors
md5-2fbe05b1f9c339be03e8a080796d2f6f
error: functions are not allowed in struct definitions
--> src/lib.rs:4:5
|
4 | fn do_something() {
| ^^^^^^^^^^^^^^^^^^^
= help: unlike in C++, Java, and C#, functions are declared in `impl` blocks
= help: see https://doc.rust-lang.org/book/ch05-03-method-syntax.html for more information
By the way, the second error about expected `:` is no longer present on nightly.
What are the chances we can also provide a mechanically applicable suggestion here that adds an impl block?
What are the chances we can also provide a mechanically applicable suggestion here that adds an impl block?
For a while I've been thinking about writing a generic "item muncher" to be used as a fall-through parser to have a very rudimentary check for "item-like" blocks.
If we had something like that, we could get a reasonable span for the incorrectly nested item, to recover the parse state for the struct (as we already do, we just ignore everything after the parse error other than nesting braces, instead of trying to identify what we've found) and get an appropriate span for an inherent impl block.
I was sure there was a ticket for this already, but I cannot find it :)
By the way, the second error about expected
:is no longer present on nightly.
I鈥檇 like to try to do the first step of changing the current diagnostic
Most helpful comment
I鈥檇 like to try to do the first step of changing the current diagnostic