Tracking Issue for `destructuring_assignment` #71126

varkor · 2020-04-14T13:55:26Z

This is a tracking issue for the RFC "Destructuring assignment" (rust-lang/rfcs#2909).
The feature gate for the issue is #![feature(destructuring_assignment)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Open a pull request: Implement destructuring assignment #71156
- Tuples (Implement destructuring assignment for tuples #78748)
- Structs and slices (Implement destructuring assignment for structs and slices #78836)
- _ expressions (Make _ an expression, to discard values in destructuring assignments #79016)
Open an RFC: Destructuring assignment rfcs#2909.
Adjust documentation (see instructions on rustc-dev-guide)
Stabilization PR (Stabilize destructuring_assignment #90521)

Implementation history

The initial implementation was carried out in three steps by @fanzier (split out from an initial implementation, #71156):

Implementing destructuring support for tuples: Implement destructuring assignment for tuples #78748
Implementing destructuring support for structs and slices: Implement destructuring assignment for structs and slices #78836
Implementing destructuring support for _ expressions: Make _ an expression, to discard values in destructuring assignments #79016

The text was updated successfully, but these errors were encountered:

varkor · 2020-04-17T18:02:22Z

We've opened an RFC for destructuring assignment: rust-lang/rfcs#2909.

…enkov Implement destructuring assignment for tuples This is the first step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: rust-lang#71126). This PR is the first part of rust-lang#71156, which was split up to allow for easier review. Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple. It is implemented via a desugaring (AST -> HIR lowering) as follows: ```rust (a,b) = (1,2) ``` ... becomes ... ```rust { let (lhs0,lhs1) = (1,2); a = lhs0; b = lhs1; } ``` Thanks to `@varkor` who helped with the implementation, particularly around default binding modes. r? `@petrochenkov`

…ing, r=petrochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: rust-lang#71126). This PR is the second part of rust-lang#71156, which was split up to allow for easier review. Note that the first PR (rust-lang#78748) is not merged yet, so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If `@petrochenkov` prefers to wait until the first PR is merged, I totally understand, of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this, the following *parser change* was necessary: struct expressions are not required to have a base expression, i.e. `Struct { a: 1, .. }` becomes legal (in order to act like a struct pattern). Unfortunately, this PR slightly regresses the diagnostics implemented in rust-lang#77283. However, it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet, I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to `@varkor` who helped with the implementation, particularly around the struct rest changes. r? `@petrochenkov`

…ing, r=petrochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: rust-lang#71126). This PR is the second part of rust-lang#71156, which was split up to allow for easier review. Note that the first PR (rust-lang#78748) is not merged yet, so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged, I totally understand, of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this, the following *parser change* was necessary: struct expressions are not required to have a base expression, i.e. `Struct { a: 1, .. }` becomes legal (in order to act like a struct pattern). Unfortunately, this PR slightly regresses the diagnostics implemented in rust-lang#77283. However, it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet, I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to ``@varkor`` who helped with the implementation, particularly around the struct rest changes. r? ``@petrochenkov``

varkor · 2020-11-16T13:14:55Z

Now that #78748, #78836, and #79016 have been merged, destructuring assignment is now implemented. Thanks to @fanzier for their hard work implementing this feature!

…ing, r=petrochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: rust-lang#71126). This PR is the second part of rust-lang#71156, which was split up to allow for easier review. Note that the first PR (rust-lang#78748) is not merged yet, so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged, I totally understand, of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this, the following *parser change* was necessary: struct expressions are not required to have a base expression, i.e. `Struct { a: 1, .. }` becomes legal (in order to act like a struct pattern). Unfortunately, this PR slightly regresses the diagnostics implemented in rust-lang#77283. However, it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet, I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to ``@varkor`` who helped with the implementation, particularly around the struct rest changes. r? ``@petrochenkov``

…etrochenkov Make `_` an expression, to discard values in destructuring assignments This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: rust-lang#71126). This PR is the third and final part of rust-lang#71156, which was split up to allow for easier review. With this PR, an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value, similarly to the wildcard `_` in patterns. For instance, ```rust (a, _) = (1, 2) ``` will simply assign 1 to `a` and discard the 2. Note that for consistency, ``` _ = foo ``` is also allowed and equivalent to just `foo`. Thanks to ````@varkor```` who helped with the implementation, particularly around pre-expansion gating. r? ````@petrochenkov````

bstrie · 2021-02-17T21:37:48Z

I got kind of a weird error message recently that probably isn't too concerning, but maybe someone more familiar with the implementation of the _ desugaring might have more insight.

The following extremely weird program:

fn main() {
    let y = Some(42);
    if y < Some(_) {}
}

Errors with:

error[E0658]: destructuring assignments are unstable
 --> src/main.rs:3:17
  |
3 |     if y < Some(_) {}
  |                 ^
  |
  = note: see issue #71126 <https://github.com/rust-lang/rust/issues/71126> for more information
  = help: add `#![feature(destructuring_assignment)]` to the crate attributes to enable

error: in expressions, `_` can only be used on the left-hand side of an assignment
 --> src/main.rs:3:17
  |
3 |     if y < Some(_) {}
  |                 ^ `_` not allowed here

error: aborting due to 2 previous errors

I'm wondering whether it's considered a problem that the compiler appears to consider Some(_) to be part of a destructuring assignment. Obviously even if this feature were stabilized this program would still error out, but I found it surprising.

fanzier · 2021-02-17T22:14:38Z

@bstrie Thanks for reporting this. The error message is indeed a bit misleading.

I'm wondering whether it's considered a problem that the compiler appears to consider Some(_) to be part of a destructuring assignment.

In fact, the compiler does not consider this _ to be part of a destructuring assignment. However, the feature destructuring assignments allows _ to occur in more places than before (namely the left-hand side of an assignment). This necessitated a parser change: we allow _ syntactically anywhere in an expression and only check later on that it only occurs on the left-hand side of an assignment. That parser change is feature-gated on destructuring assignments. If the _ indeed occurs on the LHS of an assignment, the error message is correct because there it is only allowed if the destructuring assignments feature is enabled. Otherwise, the error message is misleading because _ is illegal in all other expressions and that has nothing to do with destructuring assignments.

I didn't think this was a big problem because as soon as destructuring assignments are stabilized, you'll just get the second error message (_ can only be used on the left-hand side of an assignment), which is correct. I'm not sure what the best fix for this would be. Do you think it is important to fix while the feature is unstable?

scottmcm · 2021-02-17T22:18:36Z

I think this is ok -- the older one wasn't particularly amazing:

error: expected expression, found reserved identifier `_`
 --> <source>:3:17
  |
3 |     if y < Some(_) {}
  |                 ^ expected expression

That said, it might be nice to tune the error based on whether there's a = nearby -- it could be nice to talk about patterns and destructuring assignments as places for _s, for example.

bstrie · 2021-02-17T23:29:54Z

Do you think it is important to fix while the feature is unstable?

No, I was just surprised and wanted to make sure this wasn't indicative of some deeper bug. :) Ship it!

doivosevic · 2021-04-19T14:48:42Z

Hey everyone. I'm relatively new so I might be missing something, but I can't see what is the roadmap for this feature. Is this expected to release in the next version of Rust?

bstrie · 2021-04-19T15:03:42Z

The next step is for someone on the lang team to propose a final comment period, after which the feature can be stabilized. I'll bring it up with the lang team on Zulip.

joshtriplett · 2021-04-19T21:38:02Z

@bstrie This needs a stabilization report.

curldivergence · 2021-08-09T14:02:42Z

Hello @bstrie, are there any news on the stabilization, by any chance? :)

rfcbot · 2021-10-12T16:08:15Z

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

rfcbot · 2021-10-19T17:21:15Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot · 2021-10-29T17:23:43Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

nikomatsakis · 2021-11-02T21:30:34Z

@rfcbot reviewed

I'm excited about this :)

varkor · 2021-11-03T00:48:33Z

Now that the final comment period has ended, anyone can open up a stabilisation PR. The process is very straightforward, and essentially involves removing the destructuring_assignment feature gate wherever it currently appears in the compiler. I'm also not quite sure what the state of documentation is: it may be that pull requests (or at the very least issues) need to be opened on the repositories for the Rust book and the reference.

jhpratt · 2021-11-03T01:02:09Z

I'll take a shot at a stabilization PR.

jhpratt · 2021-11-03T06:56:04Z

PR is up: #90521

leonardo-m · 2021-11-08T20:19:49Z

Something related in C# 10:
https://docs.microsoft.com/en-us/dotnet/csharp/fundamentals/functional/deconstruct

…ignment, r=jackh726,pnkfelix Stabilize `destructuring_assignment` Closes rust-lang#71126 - [Stabilization report](rust-lang#71126 (comment)) - [Completed FCP](rust-lang#71126 (comment)) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.

…r=jackh726,pnkfelix Stabilize `destructuring_assignment` Closes #71126 - [Stabilization report](rust-lang/rust#71126 (comment)) - [Completed FCP](rust-lang/rust#71126 (comment)) `@rustbot` label +F-destructuring-assignment +T-lang Also needs +relnotes but I don't have permission to add that tag.

The usage of the `destrucuring_assignment` feature was added just for fun, it only saves two lines of code. The feature is soon stable, see rust-lang/rust#71126.

The 'destructuring_assignment' to tuples [1] was not stable with rust toolchina 1.56. [1] rust-lang/rust#71126 Signed-off-by: Bo Chen <chen.bo@intel.com>

varkor added T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Apr 14, 2020

fanzier mentioned this issue Apr 14, 2020

Implement destructuring assignment #71156

Closed

nikomatsakis mentioned this issue Oct 27, 2020

Destructuring assignment rust-lang/rfcs#2909

Merged

varkor changed the title ~~[WIP] Tracking Issue for destructuring_assignment~~ Tracking Issue for destructuring_assignment Oct 27, 2020

This was referenced Nov 4, 2020

Implement destructuring assignment for tuples #78748

Merged

Implement destructuring assignment for structs and slices #78836

Merged

fanzier mentioned this issue Nov 13, 2020

Make _ an expression, to discard values in destructuring assignments #79016

Merged

varkor added the F-destructuring_assignment `#![feature(destructuring_assignment)]` label Nov 19, 2020

dtolnay mentioned this issue Nov 27, 2020

Parse destructuring assignment syntax dtolnay/syn#933

Closed

andll mentioned this issue Dec 31, 2020

Destructuring assignment is not parsed correctly intellij-rust/intellij-rust#6598

Open

miDeb mentioned this issue Apr 1, 2021

sort: implement -k and -t support uutils/coreutils#1996

Merged

msklywenn mentioned this issue Apr 27, 2021

Smooth Damp bevyengine/bevy#2001

Closed

jbtrystram mentioned this issue May 19, 2021

Overriding the context fails drogue-iot/drg#70

Closed

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Oct 12, 2021

rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Oct 19, 2021

moxian mentioned this issue Oct 20, 2021

feature(destructuring_assignment) suggested errorneously #90095

Open

rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Oct 29, 2021

rfcbot added the to-announce Announce this issue on triage meeting label Oct 29, 2021

jhpratt mentioned this issue Nov 3, 2021

Stabilize destructuring_assignment #90521

Merged

apiraino removed the to-announce Announce this issue on triage meeting label Nov 18, 2021

varkor mentioned this issue Dec 11, 2021

Document destructuring assignment rust-lang/reference#1116

Merged

bors closed this as completed in d258e92 Dec 15, 2021

rpjohnst mentioned this issue Feb 14, 2022

destructuring assignment and let else #93995

Closed

magnunm added a commit to magnunm/rule110 that referenced this issue Mar 14, 2022

Refactor calculation of next world.

ed49020

The usage of the `destrucuring_assignment` feature was added just for fun, it only saves two lines of code. The feature is soon stable, see rust-lang/rust#71126.

lopopolo mentioned this issue Apr 6, 2022

Upgrade Rust toolchain to 1.59.0 artichoke/artichoke#1753

Merged

SPLStarX mentioned this issue May 5, 2022

Tracking Issue for cargo build (when i entered cargo build for compile the solana-runtime v1.10.12 it shows following error please help #96729

Closed

peterschutt mentioned this issue Jul 14, 2022

Issue #177: Add a baseline for Rust path resolution bindings litestar-org/litestar#270

Merged

bentpetersendk mentioned this issue Aug 9, 2022

type parameters must be declared prior to const parameters malthesr/winsfs#1

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking Issue for `destructuring_assignment` #71126

Tracking Issue for `destructuring_assignment` #71126

varkor commented Apr 14, 2020 •

edited

varkor commented Apr 17, 2020

varkor commented Nov 16, 2020

bstrie commented Feb 17, 2021

fanzier commented Feb 17, 2021

scottmcm commented Feb 17, 2021 •

edited

bstrie commented Feb 17, 2021

doivosevic commented Apr 19, 2021

bstrie commented Apr 19, 2021

joshtriplett commented Apr 19, 2021

curldivergence commented Aug 9, 2021

rfcbot commented Oct 12, 2021 •

edited by joshtriplett

rfcbot commented Oct 19, 2021

rfcbot commented Oct 29, 2021

nikomatsakis commented Nov 2, 2021

varkor commented Nov 3, 2021

jhpratt commented Nov 3, 2021

jhpratt commented Nov 3, 2021

leonardo-m commented Nov 8, 2021

Tracking Issue for destructuring_assignment #71126

Tracking Issue for destructuring_assignment #71126

Comments

varkor commented Apr 14, 2020 • edited

About tracking issues

Steps

Implementation history

varkor commented Apr 17, 2020

varkor commented Nov 16, 2020

bstrie commented Feb 17, 2021

fanzier commented Feb 17, 2021

scottmcm commented Feb 17, 2021 • edited

bstrie commented Feb 17, 2021

doivosevic commented Apr 19, 2021

bstrie commented Apr 19, 2021

joshtriplett commented Apr 19, 2021

curldivergence commented Aug 9, 2021

rfcbot commented Oct 12, 2021 • edited by joshtriplett

rfcbot commented Oct 19, 2021

rfcbot commented Oct 29, 2021

nikomatsakis commented Nov 2, 2021

varkor commented Nov 3, 2021

jhpratt commented Nov 3, 2021

jhpratt commented Nov 3, 2021

leonardo-m commented Nov 8, 2021

Tracking Issue for `destructuring_assignment` #71126

Tracking Issue for `destructuring_assignment` #71126

varkor commented Apr 14, 2020 •

edited

scottmcm commented Feb 17, 2021 •

edited

rfcbot commented Oct 12, 2021 •

edited by joshtriplett