Skip to content
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

Update wildcards.md #19341

Merged
merged 1 commit into from
Jan 3, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
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
Loading