Code
#[derive(Default)]
struct X {
field1: (),
field2: (),
}
fn main() {
let x = Default::default();
let X { field1 } = x;
}Current output
error[E0027]: pattern does not mention field `field2`
--> src/main.rs:9:9
|
9 | let X { field1 } = x;
| ^^^^^^^^^^^^ missing field `field2`
|
help: include the missing field in the pattern
|
9 | let X { field1, field2 } = x;
| ~~~~~~~~~~
help: if you don't care about this missing field, you can explicitly ignore it
|
9 | let X { field1, .. } = x;
| ~~~~~~
Desired output
error[E0027]: pattern does not mention field `field2`
--> src/main.rs:9:9
|
9 | let X { field1 } = x;
| ^^^^^^^^^^^^ missing field `field2`
|
help: include the missing field in the pattern
|
9 | let X { field1, field2 } = x;
| ~~~~~~~~~~
help: if you don't care about this missing field, you can explicitly ignore it
|
9 | let X { field1, field2: _ } = x;
| ~~~~~~~~~~~~~
help: if you only care about the specified fields, you can explicitly ignore all other fields
|
9 | let X { field1, .. } = x;
| ~~~~~~
Rationale and extra context
I often find myself trying to write code in such a way that future changes to a struct, require me to look at all uses, since they may not accurately reflect what I want after the refactoring. The current suggestion actively goes against that, ignoring future field-additions.
Ignoring fields is of course still a valid option in some cases, so the new suggestion would give both variants, allowing the user to choose which is more appropriate in this case (and making them aware of the trade-offs).
At the very least the message should reflect the trade-offs made when writing .. (also ignoring all fields added in the future).
Other cases
The error message for three fields:
error[E0027]: pattern does not mention fields `field2`, `field3`
--> src/main.rs:10:9
|
10 | let X { field1 } = x;
| ^^^^^^^^^^^^ missing fields `field2`, `field3`
|
help: include the missing fields in the pattern
|
10 | let X { field1, field2, field3 } = x;
| ~~~~~~~~~~~~~~~~~~
help: if you don't care about these missing fields, you can explicitly ignore them
|
10 | let X { field1, .. } = x;
| ~~~~~~
It is unclear to me whether for more than one field the error message should just scale to more fields (field2: _, field3: _) or just suggest the .. syntax and warn that it might result in unwanted ignored fields if more fields are added.
Rust Version
rustc 1.84.0-nightly (662180b34 2024-10-20)
binary: rustc
commit-hash: 662180b34d95f72d05b7c467b0baf4d23d36b1e1
commit-date: 2024-10-20
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.1
Anything else?
No response
Code
Current output
Desired output
Rationale and extra context
I often find myself trying to write code in such a way that future changes to a
struct, require me to look at all uses, since they may not accurately reflect what I want after the refactoring. The current suggestion actively goes against that, ignoring future field-additions.Ignoring fields is of course still a valid option in some cases, so the new suggestion would give both variants, allowing the user to choose which is more appropriate in this case (and making them aware of the trade-offs).
At the very least the message should reflect the trade-offs made when writing
..(also ignoring all fields added in the future).Other cases
The error message for three fields:
It is unclear to me whether for more than one field the error message should just scale to more fields (
field2: _, field3: _) or just suggest the..syntax and warn that it might result in unwanted ignored fields if more fields are added.Rust Version
Anything else?
No response