Skip to content

Commit

Permalink
Update wildcards.md
Browse files Browse the repository at this point in the history
The documentation gives incorrect Scala versions for the transitions.
  • Loading branch information
Bersier authored Dec 28, 2023
1 parent b36f728 commit 074128b
Showing 1 changed file with 8 additions and 8 deletions.
16 changes: 8 additions & 8 deletions docs/_docs/reference/changed-features/wildcards.md
Original file line number Diff line number Diff line change
Expand Up @@ -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]
Expand All @@ -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
Expand All @@ -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`:
Expand All @@ -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.
Expand Down

0 comments on commit 074128b

Please sign in to comment.