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

Is it possible to destructure fields from a Class? #2822

Closed
mnordine opened this issue Feb 6, 2023 · 5 comments
Closed

Is it possible to destructure fields from a Class? #2822

mnordine opened this issue Feb 6, 2023 · 5 comments
Labels
feature Proposed language feature that solves one or more problems

Comments

@mnordine
Copy link
Contributor

mnordine commented Feb 6, 2023

Tried this:

class Point {
  final int x;
  final int y;

  Point(this.x, this.y);
}

void main() {
  final (:x, :y) = Point(1, 5);
  print('$x, $y');
}

Got:

The matched value of type 'Point' isn't assignable to the required type '({Object? x, Object? y})'.
Try changing the required type of the pattern, or the matched value type.dart(pattern_type_mismatch_in_irrefutable_context)
@mnordine mnordine added the feature Proposed language feature that solves one or more problems label Feb 6, 2023
@mateusfccp
Copy link
Contributor

mateusfccp commented Feb 6, 2023

I think the specified syntax for destructuring classes in variable assignments would be:

final Point(:x, :y) = Point(1, 5);

@mnordine
Copy link
Contributor Author

mnordine commented Feb 6, 2023

Yep, the analyzer does seem to accept that. Shouldn't this be inferred, though?

@mateusfccp
Copy link
Contributor

I think this is a way to disambiguate from regular records destructuring? I don't know if there's any implication in allowing your proposed syntax.

@munificent
Copy link
Member

There was a point in time when the proposal did allow the name to be inferred, yes. But we removed that because it broke being able to actually match a record object in places where the matched value is a supertype of Record. I would very much like to get it back (#2563) but we won't in time for 3.0.

@mnordine
Copy link
Contributor Author

mnordine commented Feb 7, 2023

Thx, in that case I'll close this dupe.

@mnordine mnordine closed this as completed Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Proposed language feature that solves one or more problems
Projects
None yet
Development

No branches or pull requests

3 participants