From 074128b9f2d6bce066e7137042b19dd401353ecc Mon Sep 17 00:00:00 2001 From: Bersier Date: Thu, 28 Dec 2023 11:21:51 -0500 Subject: [PATCH] Update wildcards.md The documentation gives incorrect Scala versions for the transitions. --- .../reference/changed-features/wildcards.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/_docs/reference/changed-features/wildcards.md b/docs/_docs/reference/changed-features/wildcards.md index 0d3e13c3d7e0..ac7235770e36 100644 --- a/docs/_docs/reference/changed-features/wildcards.md +++ b/docs/_docs/reference/changed-features/wildcards.md @@ -4,7 +4,7 @@ title: Wildcard Arguments in Types nightlyOf: https://docs.scala-lang.org/scala3/reference/changed-features/wildcards.html --- -The syntax of wildcard arguments in types has changed from `_` to `?`. Example: +The syntax of wildcard arguments in types is changing from `_` to `?`. Example: ```scala List[?] Map[? <: AnyRef, ? >: Null] @@ -14,8 +14,8 @@ Map[? <: AnyRef, ? >: Null] We would like to use the underscore syntax `_` to stand for an anonymous type parameter, aligning it with its meaning in value parameter lists. So, just as `f(_)` is a shorthand for the lambda `x => f(x)`, in the future `C[_]` will be a shorthand -for the type lambda `[X] =>> C[X]`. This makes higher-kinded types easier to use. It also removes the wart that, used as a type -parameter, `F[_]` means `F` is a type constructor whereas used as a type, `F[_]` means it is a wildcard (i.e. existential) type. +for the type lambda `[X] =>> C[X]`. This will make higher-kinded types easier to use. It will also remove the wart that, used as a type +parameter, `F[_]` means `F` is a type constructor, whereas used as a type, `F[_]` means it is a wildcard (i.e. existential) type. In the future, `F[_]` will mean the same thing, no matter where it is used. We pick `?` as a replacement syntax for wildcard types, since it aligns with @@ -28,11 +28,11 @@ compiler plugin still uses the reverse convention, with `?` meaning parameter pl A step-by-step migration is made possible with the following measures: - 1. In Scala 3.0, both `_` and `?` are legal names for wildcards. - 2. In Scala 3.1, `_` is deprecated in favor of `?` as a name for a wildcard. A `-rewrite` option is + 1. In earlier versions of Scala 3, both `_` and `?` are legal names for wildcards. + 2. In Scala 3.4, `_` will be deprecated in favor of `?` as a name for wildcards. A `-rewrite` option is available to rewrite one to the other. - 3. In Scala 3.2, the meaning of `_` changes from wildcard to placeholder for type parameter. - 4. The Scala 3.1 behavior is already available today under the `-source future` setting. + 3. At some later point in the future, the meaning of `_` will change from wildcard to placeholder for type parameters. + 4. Some deprecation warnings are already available under the `-source future` setting. To smooth the transition for codebases that use kind-projector, we adopt the following measures under the command line option `-Ykind-projector`: @@ -42,7 +42,7 @@ option `-Ykind-projector`: available to rewrite one to the other. 3. In Scala 3.3, `*` is removed again, and all type parameter placeholders will be expressed with `_`. -These rules make it possible to cross build between Scala 2 using the kind projector plugin and Scala 3.0 - 3.2 using the compiler option `-Ykind-projector`. +These rules make it possible to cross-build between Scala 2 using the kind projector plugin and Scala 3.0 - 3.2 using the compiler option `-Ykind-projector`. There is also a migration path for users that want a one-time transition to syntax with `_` as a type parameter placeholder. With option `-Ykind-projector:underscores` Scala 3 will regard `_` as a type parameter placeholder, leaving `?` as the only syntax for wildcards.