Skip to content

Pattern-bound type refs should have Case flag set #6172

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

Merged
merged 2 commits into from
Mar 27, 2019

Conversation

milessabin
Copy link
Contributor

Fixes #6157.

@milessabin milessabin requested a review from abgruszecki March 26, 2019 14:01
@smarter
Copy link
Member

smarter commented Mar 26, 2019

I don't know what this does but the description of this flag is manifestly incomplete:
https://github.com/lampepfl/dotty/blob/d2499265ab2d13bf70eee17bfad67734804fecd9/compiler/src/dotty/tools/dotc/core/Flags.scala#L293-L294

Could you update it to explain what Case does on a val ?

@abgruszecki abgruszecki self-requested a review March 26, 2019 14:49
Copy link
Contributor

@abgruszecki abgruszecki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're going with what @smarter proposed, then how about the following?

  /** A symbol related to pattern matching */
  final val Case: FlagSet = commonFlag(17, "case")
  /** Case class or pattern-bound type symbol. */
  final val CaseType: FlagSet = Case.toTypeFlags
  /** Case class' companion object or pattern-bound term symbol */
  final val CaseVal: FlagSet = Case.toTermFlags

Refactoring necessary to change usages of CaseClass (which doesn't really mark solely case classes).

@smarter
Copy link
Member

smarter commented Mar 26, 2019

Sounds like these two usages of the flag are completely unrelated, so it'd be clearer to use two flags (we're not running out of bits for them yet).

@milessabin
Copy link
Contributor Author

I agree that it looks like we have two distinct uses of the same flag here.

I think that using Case to represent case classes came first. Do you know who repurposed it to mean pattern bound type variable and why?

@smarter
Copy link
Member

smarter commented Mar 26, 2019

I think it was just done for convenience and there's no deep reason for it, you have my blessing to add a PatternBound flag :).

@odersky
Copy link
Contributor

odersky commented Mar 27, 2019

We are not that far to running out of flags, so I vote for keeping a single Case flag but documenting carefully the different meanings.

@milessabin
Copy link
Contributor Author

@odersky I'll add a comment to this PR.

@smarter
Copy link
Member

smarter commented Mar 27, 2019

OK, in that case maybe call the flag PatternBoundOrCase so it's more obvious that it has a dual meaning, and add convenience methods like def isCaseClass(implicit ctx: Context) = isClass && is(PatternBoundOrCase) to SymDenotation.

@milessabin
Copy link
Contributor Author

@smarter OK, but I'd rather do that in a followup PR.

@milessabin
Copy link
Contributor Author

Follow on issue here, assigned to me.

Any objections if I merge this now?

@milessabin milessabin dismissed abgruszecki’s stale review March 27, 2019 12:15

Comments addressed either here or TBD in follow on issue.

@milessabin milessabin merged commit 8e4b919 into scala:master Mar 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants