Skip to content

Support case in pattern bindings under -Xsource:3#9558

Merged
lrytz merged 1 commit intoscala:2.13.xfrom
smarter:case-pattern-binding
Apr 20, 2021
Merged

Support case in pattern bindings under -Xsource:3#9558
lrytz merged 1 commit intoscala:2.13.xfrom
smarter:case-pattern-binding

Conversation

@smarter
Copy link
Member

@smarter smarter commented Mar 30, 2021

Just like in Scala 3.0, adding this keyword doesn't change anything, but
it will be required in future versions of Scala 3 for non-exhaustive
patterns in a for comprehension. We would like to start issuing warnings
by default in Scala 3 for code which does not use case in those
situations, but to not hamper cross-compilation we need Scala 2 to also
support that keyword.

For details, see:
https://dotty.epfl.ch/docs/reference/changed-features/pattern-bindings.html

Just like in Scala 3.0, adding this keyword doesn't change anything, but
it will be required in future versions of Scala 3 for non-exhaustive
patterns in a for comprehension. We would like to start issuing warnings
by default in Scala 3 for code which does not use `case` in those
situations, but to not hamper cross-compilation we need Scala 2 to also
support that keyword.

For details, see:
https://dotty.epfl.ch/docs/reference/changed-features/pattern-bindings.html
@scala-jenkins scala-jenkins added this to the 2.13.6 milestone Mar 30, 2021
@dwijnand
Copy link
Member

dwijnand commented Mar 30, 2021

As using the keyword didn't compile before, I'm happy (and eager) to have this unflagged.

Does using case (x, y) <- ... still mean filter/withFilter, in Scala 3?

@smarter
Copy link
Member Author

smarter commented Mar 30, 2021

Yes.

@smarter
Copy link
Member Author

smarter commented Mar 30, 2021

I'm happy (and eager) to have this unflagged.

I thought about having it by default, but it seems like something that would require cooperation with scalameta at least.

@smarter
Copy link
Member Author

smarter commented Mar 31, 2021

If I were to make a PR to get this (and other similar changes) in Scala 2.12, could it get in?

@SethTisue SethTisue added the release-notes worth highlighting in next release notes label Apr 8, 2021
@SethTisue
Copy link
Member

SethTisue commented Apr 8, 2021

If I were to make a PR to get this (and other similar changes) in Scala 2.12, could it get in?

Yes, but 2.12 doesn't have -Xsource:3 yet I don't think. I can't think of any reason it shouldn't be added.

@smarter
Copy link
Member Author

smarter commented Apr 19, 2021

Ping for review.

@lrytz lrytz merged commit 87b0c70 into scala:2.13.x Apr 20, 2021
smarter added a commit to smarter/scala that referenced this pull request Aug 9, 2021
In scala#9558 (which shipped with 2.13.6) we added support for `case` bindings
under -Xsource:3. Since this parser change does not break any existing
code and since IntelliJ and scalameta/metals now understand this syntax
in Scala 2 code, it should be safe to enable it by default to further
ease cross-compilation between Scala 2 and 3.
smarter added a commit to smarter/scala that referenced this pull request Aug 10, 2021
In scala#9558 (which shipped with 2.13.6) we added support for `case` bindings
under -Xsource:3. Since this parser change does not break any existing
code and since IntelliJ and scalameta/metals now understand this syntax
in Scala 2 code, it should be safe to enable it by default to further
ease cross-compilation between Scala 2 and 3.
smarter added a commit to smarter/scala that referenced this pull request Aug 27, 2021
In scala#9558 (which shipped with 2.13.6) we added support for `case` bindings
under -Xsource:3. Since this parser change does not break any existing
code and since IntelliJ and scalameta/metals now understand this syntax
in Scala 2 code, it should be safe to enable it by default to further
ease cross-compilation between Scala 2 and 3.
smarter added a commit to smarter/scala that referenced this pull request Aug 27, 2021
In scala#9558 (which shipped with 2.13.6) we added support for `case` bindings
under -Xsource:3. Since this parser change does not break any existing
code and since IntelliJ and scalameta/metals now understand this syntax
in Scala 2 code, it should be safe to enable it by default to further
ease cross-compilation between Scala 2 and 3.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release-notes worth highlighting in next release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants