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

how should pattern matching and implicit conversion interact? #1283

Closed
zygoloid opened this issue May 20, 2022 · 5 comments
Closed

how should pattern matching and implicit conversion interact? #1283

zygoloid opened this issue May 20, 2022 · 5 comments
Labels
leads question A question for the leads team

Comments

@zygoloid
Copy link
Contributor

See this discord thread:

Should implicit conversions be permitted in a match statement? Specifically, suppose we have impl MyInt as ImplicitAs(i32), and m: MyInt. Then presumably we want var (a: i32, b: i32) = (m, m); to be valid. But would match (m, m) { case (a: i32, b: i32) => {} } also be valid?

If so: do we require all of the patterns to have the same type, so we only convert once, or can the patterns have different types, so we convert once for each pattern?

This has implications for matching structs:

match ({.a = 1, .b = 2}) {
  case {.a = 1, .b = (b: i32)} => {}
  case {.b = 1, .a = (a: i32)} => {}
  ...
}

would not type-check if we require all the cases to have the same type.

One possible approach is suggested in this message:

Summary of in-person discussion with Chandler: We considered the option of not doing any implicit conversion on the scrutinee of a match. Instead, we could perform conversions as part of bindings:

  • A {...} pattern would match any struct type, if the struct type has the same set of field names, and the values match (recursively).
  • A (...) pattern would match any tuple type, if the elements match (recursively).
  • A binding pattern would match if the corresponding portion of the scrutinee can be implicitly converted to the specified type; for a match, the conversion is not actually done until the relevant case is selected.
  • An expression pattern would match if an == comparison between the expression and the scrutinee evaluates to true.
@geoffromer
Copy link
Contributor

  • A {...} pattern would match any struct type, if the struct type has the same set of field names, and the values match (recursively).
  • A (...) pattern would match any tuple type, if the elements match (recursively).
  • A binding pattern would match if the corresponding portion of the scrutinee can be implicitly converted to the specified type; for a match, the conversion is not actually done until the relevant case is selected.
  • An expression pattern would match if an == comparison between the expression and the scrutinee evaluates to true.

To clarify a point that confused me in the discussion: IIUC, under this formulation{...} and (...) patterns are not considered to be expression patterns (and hence are not compared using ==), even if they are valid expressions.

@jonmeow jonmeow added the leads question A question for the leads team label Aug 10, 2022
@github-actions
Copy link

github-actions bot commented Nov 9, 2022

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time.
This issue is labeled inactive because the last activity was over 90 days ago.

@github-actions github-actions bot added the inactive Issues and PRs which have been inactive for at least 90 days. label Nov 9, 2022
@josh11b
Copy link
Contributor

josh11b commented Nov 10, 2022

An answer was proposed but never accepted. Perhaps we should accept the answer for now, and revisit if needed once we have experience?

@josh11b josh11b removed the inactive Issues and PRs which have been inactive for at least 90 days. label Nov 10, 2022
@zygoloid
Copy link
Contributor Author

The proposed answer has been incorporated into #2188.

@chandlerc
Copy link
Contributor

The proposed answer has been incorporated into #2188.

And to confirm, leads are happy w/ this direction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
leads question A question for the leads team
Projects
None yet
Development

No branches or pull requests

5 participants