Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide on Rule 4 variant for match ergonomics #127257

Closed
Tracked by #123076
traviscross opened this issue Jul 3, 2024 · 1 comment
Closed
Tracked by #123076

Decide on Rule 4 variant for match ergonomics #127257

traviscross opened this issue Jul 3, 2024 · 1 comment
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@traviscross
Copy link
Contributor

traviscross commented Jul 3, 2024

In our 2024-06-26 design meeting on match ergonomics (part 3):

...we decided on a slate on rules:

  • Rule 1: When the DBM (default binding mode) is not move (whether or not behind a reference), writing mut on a binding is an error.
  • Rule 2: When a reference pattern matches against a reference, do not update the DBM.
  • Rule 3: If we've previously matched against a shared reference in the scrutinee (or against a ref DBM under Rule 4, or against a mutable reference treated as a shared one or a ref mut DBM treated as a ref one under Rule 5), set the DBM to ref whenever we would otherwise set it to ref mut.
  • Rule 4: If an & or &mut pattern is being matched against a non-reference type and if the DBM is ref or ref mut, match the pattern against the DBM as though it were a type.
  • Rule 5: If an & pattern is being matched against a mutable reference type (or against a ref mut DBM under Rule 4), act as if the type were a shared reference instead (or that the ref mut DBM is a ref DBM instead).

In discussion toward the end of and after the meeting, there emerged some potentially good reasons to adopt a slight variation of Rule 4. The motivation is that, under Rule 4, this is an error:

let [&mut x] = &mut [&T]; //~ ERROR

(T here is a unit struct that implements Copy.)

That's kind of awkward and unfortunate, because without the &mut in the pattern, we get a type of &mut &T, so we really want adding &mut to get us a &T, since, in all other cases, that's what happens.

We can make this work with a small tweak to Rule 4 (which we'll call the extended Rule 4):

  • Rule 4 (extended): If an & pattern is being matched against a non-reference type or an &mut pattern is being matched against a shared reference type or a non-reference type, and if the DBM is ref or ref mut, match the pattern against the DBM as though it were a type.

(Emphasis highlights the diff.)

We've analyzed this now, and think it's OK and a good tweak. We nominate to confirm this sounds good to the team.

If adopted, we'll revise Rule 4 to be the extended version.

Tracking:

@rustbot labels +T-lang +I-lang-nominated +C-discussion

cc @Jules-Bertholet @Nadrieril

@rustbot rustbot added needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. C-discussion Category: Discussion or questions that doesn't represent real issues. I-lang-nominated Nominated for discussion during a lang team meeting. T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Jul 3, 2024
@traviscross traviscross removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jul 3, 2024
@traviscross
Copy link
Contributor Author

@rustbot labels -I-lang-nominated

We discussed this in the triage meeting today, 2024-07-03, and we resolved via meeting consensus, with tmandry, nikomatsakis, Josh, and myself present, to adopt the extended version of Rule 4 as stated above as Rule 4, and to amend our meeting consensus from the 2024-06-26 design meeting accordingly.

The next step would be for the RFC and the experimental implementation to be updated according to Rules 1-5 as amended above.

@rustbot rustbot removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Jul 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants