Skip to content

E0027 suggestion introduces refactoring-hazard #132008

Closed
@aticu

Description

@aticu

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

Metadata

Metadata

Assignees

Labels

A-diagnosticsArea: Messages for errors, warnings, and lintsE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions