Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

smarter
Copy link
Member

@smarter smarter commented Mar 31, 2021

Like in Scala 3.0, this allows ? to be used as a type argument in all
situations where _ could be used as a wildcard previously. This should
allow us to deprecate the use of _ as a wildcard in Scala 3 to be able
to eventually repurpose it as explained in
http://dotty.epfl.ch/docs/reference/changed-features/wildcards.html

This is a source-breaking change since a type named ? is legal in
Scala 2 (but not in Scala 3 unless -source 3.0-migration is used).
? also has a special meaning when the kind-projector plugin is used,
but that usage has been deprecated in favor of * for a while now.

Like in Scala 3.0, this allows `?` to be used as a type argument in all
situations where `_` could be used as a wildcard previously. This should
allow us to deprecate the use of `_` as a wildcard in Scala 3 to be able
to eventually repurpose it as explained in
http://dotty.epfl.ch/docs/reference/changed-features/wildcards.html

This is a source-breaking change since a type named `?` is legal in
Scala 2 (but not in Scala 3 unless -source 3.0-migration is used).
`?` also has a special meaning when the kind-projector plugin is used,
but that usage has been deprecated in favor of `*` for a while now.
@scala-jenkins scala-jenkins added this to the 2.13.6 milestone Mar 31, 2021
@SethTisue SethTisue added the release-notes worth highlighting in next release notes label Mar 31, 2021
Copy link
Member

@joroKr21 joroKr21 left a comment

Choose a reason for hiding this comment

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

Nice 👍

@dwijnand
Copy link
Member

dwijnand commented Apr 1, 2021

? also has a special meaning when the kind-projector plugin is used,
but that usage has been deprecated in favor of * for a while now.

Unfortunately it looks like it was deprecated in the docs since Sep 2019 (typelevel/kind-projector#109) but only emits a deprecation warnings since the end of November 2020 (i.e. https://github.com/typelevel/kind-projector/releases/tag/v0.11.2) 😕

Copy link
Member

@dwijnand dwijnand left a comment

Choose a reason for hiding this comment

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

LGTM

@SethTisue SethTisue merged commit 411c1f7 into scala:2.13.x Apr 8, 2021
smarter added a commit to smarter/kind-projector that referenced this pull request Apr 30, 2021
Scala 2.13.6 and 2.12.14 will interpret `?` as a wildcard when using the
`-Xsource:3` flag (cf scala/scala#9560)). This
means that the old kind-projector syntax will no longer work, so it
seems like a good time to remove it. This will also allow us to compile
more of the community-build with `-Xsource:3` enabled (cf
scala/scala-dev#769).

Sincet this is a breaking change, we also bump the version to
0.12.0-SNAPSHOT.
neko-kai added a commit to 7mind/kind-projector that referenced this pull request May 7, 2021
…ymous type lambdas

The syntax roughly follows the [proposed new syntax for wildcards and placeholders](https://dotty.epfl.ch/docs/reference/changed-features/wildcards.html#migration-strategy) for Scala 3.2+ and is designed to allow cross-compilation of libraries between Scala 2 and Scala 3 while using the new Scala 3 syntax for both versions.

To enable this mode, add `-P:kind-projector:underscore-placeholders` to your scalac command-line. In sbt you may do this as follows:

```scala
ThisBuild / scalacOptions += "-P:kind-projector:underscore-placeholders"
```

This mode is designed to be used with scalac versions `2.12.14`+ and `2.13.6`+, these versions add an the ability to use `?` as the existential type wildcard ([scala/scala#9560](scala/scala#9560)), allowing to repurpose the underscore without losing the ability to write existential types. It is not advised that you use this mode with older versions of scalac or without `-Xsource:3` flag, since you will lose the underscore syntax entirely.

Here are a few examples:

```scala
Tuple2[_, Double]        // equivalent to: type R[A] = Tuple2[A, Double]
Either[Int, +_]          // equivalent to: type R[+A] = Either[Int, A]
Function2[-_, Long, +_]  // equivalent to: type R[-A, +B] = Function2[A, Long, B]
EitherT[_[_], Int, _]    // equivalent to: type R[F[_], B] = EitherT[F, Int, B]
```

Examples with `-Xsource:3`'s `?`-wildcard:

```scala
Tuple2[_, ?]        // equivalent to: type R[A] = Tuple2[A, x] forSome { type x }
Either[?, +_]          // equivalent to: type R[+A] = Either[x, A] forSome { type x }
Function2[-_, ?, +_]  // equivalent to: type R[-A, +B] = Function2[A, x, B] forSome { type x }
EitherT[_[_], ?, _]    // equivalent to: type R[F[_], B] = EitherT[F, x, B] forSome { type x }
```
neko-kai added a commit to 7mind/kind-projector that referenced this pull request May 7, 2021
…ymous type lambdas

The syntax roughly follows the [proposed new syntax for wildcards and placeholders](https://dotty.epfl.ch/docs/reference/changed-features/wildcards.html#migration-strategy) for Scala 3.2+ and is designed to allow cross-compilation of libraries between Scala 2 and Scala 3 while using the new Scala 3 syntax for both versions.

To enable this mode, add `-P:kind-projector:underscore-placeholders` to your scalac command-line. In sbt you may do this as follows:

```scala
ThisBuild / scalacOptions += "-P:kind-projector:underscore-placeholders"
```

This mode is designed to be used with scalac versions `2.12.14`+ and `2.13.6`+, these versions add an the ability to use `?` as the existential type wildcard ([scala/scala#9560](scala/scala#9560)), allowing to repurpose the underscore without losing the ability to write existential types. It is not advised that you use this mode with older versions of scalac or without `-Xsource:3` flag, since you will lose the underscore syntax entirely.

Here are a few examples:

```scala
Tuple2[_, Double]        // equivalent to: type R[A] = Tuple2[A, Double]
Either[Int, +_]          // equivalent to: type R[+A] = Either[Int, A]
Function2[-_, Long, +_]  // equivalent to: type R[-A, +B] = Function2[A, Long, B]
EitherT[_[_], Int, _]    // equivalent to: type R[F[_], B] = EitherT[F, Int, B]
```

Examples with `-Xsource:3`'s `?`-wildcard:

```scala
Tuple2[_, ?]        // equivalent to: type R[A] = Tuple2[A, x] forSome { type x }
Either[?, +_]          // equivalent to: type R[+A] = Either[x, A] forSome { type x }
Function2[-_, ?, +_]  // equivalent to: type R[-A, +B] = Function2[A, x, B] forSome { type x }
EitherT[_[_], ?, _]    // equivalent to: type R[F[_], B] = EitherT[F, x, B] forSome { type x }
```
smarter added a commit to smarter/scala that referenced this pull request May 10, 2021
scala#9560 introduced a new meaning for
`?` under `-Xsource:3`, but to smooth out the migration it'd be nice if
we could also enable this meaning by default. Before doing so, let's
deprecate any current usage of `?` as a type that isn't wrapped in
backticks.
smarter added a commit to smarter/scala that referenced this pull request May 10, 2021
scala#9560 introduced a new meaning for
`?` under `-Xsource:3`, but to smooth out the migration it'd be nice if
we could also enable this meaning by default. Before doing so, let's
deprecate any current usage of `?` as a type that isn't wrapped in
backticks.
smarter added a commit to smarter/scala that referenced this pull request May 10, 2021
scala#9560 introduced a new meaning for
`?` under `-Xsource:3`, but to smooth out the migration it'd be nice if
we could also enable this meaning by default. Before doing so, let's
deprecate any current usage of `?` as a type that isn't wrapped in
backticks.
lrytz pushed a commit to smarter/scala that referenced this pull request May 11, 2021
scala#9560 introduced a new meaning for
`?` under `-Xsource:3`, but to smooth out the migration it'd be nice if
we could also enable this meaning by default. Before doing so, let's
deprecate any current usage of `?` as a type that isn't wrapped in
backticks.
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