You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/docs/reference/changed-features/eta-expansion-spec.md
+5-3Lines changed: 5 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,11 +3,13 @@ layout: doc-page
3
3
title: "Automatic Eta Expansion - More Details"
4
4
---
5
5
6
-
###Motivation
6
+
## Motivation
7
7
8
8
Scala maintains a convenient distinction between _methods_ and _functions_.
9
9
Methods are part of the definition of a class that can be invoked in objects while functions are complete objects themselves, making them first-class entities. For example, they can be assigned to variables.
10
-
These two mechanisms are bridged in Scala by a mechanism called _eta-expansion_ (also called eta-abstraction), which converts a reference to a method into a function. Intuitively, a method `m` can be passed around by turning it into an object: the function `x => m(x)`.
10
+
These two mechanisms are bridged in Scala by a mechanism called
(also called eta-abstraction), which converts a reference to a method into a function. Intuitively, a method `m` can be passed around by turning it into an object: the function `x => m(x)`.
11
13
12
14
In this snippet which assigns a method to a `val`, the compiler will perform _automatic eta-expansion_, as shown in the comment:
13
15
@@ -69,6 +71,6 @@ Thus, an unapplied method with an empty argument list is only converted to a fun
69
71
70
72
The method value syntax `m _` is deprecated.
71
73
72
-
###Reference
74
+
## Reference
73
75
74
76
For more info, see [PR #2701](https://github.com/lampepfl/dotty/pull/2701).
Copy file name to clipboardExpand all lines: docs/docs/reference/changed-features/implicit-resolution.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
layout: doc-page
3
3
title: "Changes in Implicit Resolution"
4
4
---
5
-
This page describes changes to the implicit resolution that apply both to the new `given`s and to the old-style `implicit`s in Scala 3.
5
+
This section describes changes to the implicit resolution that apply both to the new `given`s and to the old-style `implicit`s in Scala 3.
6
6
Implicit resolution uses a new algorithm which caches implicit results
7
7
more aggressively for performance. There are also some changes that
8
8
affect implicits on the language level.
@@ -20,8 +20,8 @@ where the type may still be inferred:
20
20
/*!*/implicitdefy= ... // error: type must be given explicitly
21
21
22
22
valy= {
23
-
implicitvalctx=this.ctx // ok
24
-
...
23
+
implicitvalctx=this.ctx // ok
24
+
...
25
25
}
26
26
```
27
27
**2.**Nesting is now taken into account for selecting an implicit. Considerfor instance the following scenario:
@@ -114,7 +114,7 @@ the implicit search for `Q` fails.
114
114
**5.**The treatment of divergence errors has also changed. A divergent implicit is treated asa normal failure, after which alternatives are still tried. This also makes sense: Encountering a divergent implicit means that we assume that no finite solution can be found on the corresponding path, but another path can still be tried. By contrast,
115
115
most (but not all) divergence errors in Scala2 would terminate the implicit search asa whole.
116
116
117
-
**6.**Scala-2 gives a lower level of priority to implicit conversions with call-by-name parameters relative to implicit conversions with call-by-value parameters. Scala3 drops this distinction. So the following code snippet would be ambiguous in Scala3:
117
+
**6.**Scala2 gives a lower level of priority to implicit conversions with call-by-name parameters relative to implicit conversions with call-by-value parameters. Scala3 drops this distinction. So the following code snippet would be ambiguous in Scala3:
A bound like `: Ord` on a type parameter `T` of a method or class indicates a context parameter `with Ord[T]`. The context parameter(s) generated from context bounds come last in the definition of the containing method or class. E.g.,
12
+
A bound like `: Ord` on a type parameter `T` of a method or class indicates a context parameter `with Ord[T]`. The context parameter(s) generated from context bounds come last in the definition of the containing method or class. For instance,
Copy file name to clipboardExpand all lines: docs/docs/reference/contextual/conversions.md
+3-2Lines changed: 3 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,8 @@ title: "Implicit Conversions"
6
6
Implicit conversions are defined by given instances of the `scala.Conversion` class.
7
7
This class is defined in package `scala` as follows:
8
8
```scala
9
-
abstractclassConversion[-T, +U] extends (T=>U)
9
+
abstractclassConversion[-T, +U] extends (T=>U):
10
+
defapply (x: T):U
10
11
```
11
12
For example, here is an implicit conversion from `String` to `Token`:
12
13
```scala
@@ -41,7 +42,7 @@ given int2Integer: Conversion[Int, java.lang.Integer] =
41
42
java.lang.Integer.valueOf(_)
42
43
```
43
44
44
-
2. The "magnet" pattern is sometimes used to express many variants of a method. Instead of defining overloaded versions of the method, one can also let the method take one or more arguments of specially defined "magnet" types, into which various argument types can be converted. E.g.
45
+
2. The "magnet" pattern is sometimes used to express many variants of a method. Instead of defining overloaded versions of the method, one can also let the method take one or more arguments of specially defined "magnet" types, into which various argument types can be converted. Example:
0 commit comments