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/contextual/motivation.md
+3-4Lines changed: 3 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -29,7 +29,7 @@ Particular criticisms are:
29
29
30
30
3. The syntax of implicit definitions is too minimal. It consists of a single modifier, `implicit`, that can be attached to a large number of language constructs. A problem withthisfor newcomers is that it conveys mechanism instead of intent. For instance, a typeclass instance is an implicitobjectorvalif unconditional and an implicitdefwithimplicit parameters referring to some classif conditional. This describes precisely what the implicit definitions translate to -- just drop the `implicit` modifier, and that's it!But the cues that define intent are rather indirect and can be easily misread, asdemonstrated by the definitions of `i1` and `i2` above.
31
31
32
-
4. The syntax of implicit parameters also has shortcomings. It starts with the position of `implicit` asa pseudo-modifier that applies to a whole parameter section instead of a single parameter. This represents an irregular casewrt to the rest of Scala's syntax. Furthermore, whileimplicit _parameters_ are designated specifically, arguments are not. Passing an argument to an implicit parameter looks like a regular application `f(arg)`. This is problematic because it means there can be confusion regarding what parameter gets instantiated in a call. For instance, in
32
+
4. The syntax of implicit parameters also has shortcomings. It starts with the position of `implicit` asa pseudo-modifier that applies to a whole parameter section instead of a single parameter. This represents an irregular casewith respect to the rest of Scala's syntax. Furthermore, whileimplicit _parameters_ are designated specifically, arguments are not. Passing an argument to an implicit parameter looks like a regular application `f(arg)`. This is problematic because it means there can be confusion regarding what parameter gets instantiated in a call. For instance, in
None of the shortcomings is fatal, after all implicits are very widely used, and many libraries and applications rely on them. But together, they make code using implicits a lot more cumbersome and less clear than it could be.
41
41
42
-
Historically, many of these shortcomings come from the way implicits were gradually "discovered" in Scala. Scala originally had only implicit conversions with the intended use case of "extending" a classortraitafter it was defined, i.e. what is expressed by implicit classes in later versions of Scala. Implicit parameters and instance definitions came later in 2006 and picked similar syntax since it seemed convenient. For the same reason, no effort was made to distinguish implicit imports or arguments from normal ones.
42
+
Historically, many of these shortcomings come from the way implicits were gradually "discovered" in Scala. Scala originally had only implicit conversions with the intended use case of "extending" a classortraitafter it was defined, i.e. what is expressed by implicit classes in later versions of Scala. Implicit parameters and instance definitions came later in 2006 and we picked similar syntax since it seemed convenient. For the same reason, no effort was made to distinguish implicit imports or arguments from normal ones.
43
43
44
44
ExistingScala programmers by and large have gotten used to the status quo and see little need for change. Butfor newcomers this status quo presents a big hurdle. I believe if we want to overcome that hurdle, we should take a step back and allow ourselves to consider a radically new design.
45
45
@@ -61,8 +61,7 @@ This section also contains pages describing other language features that are rel
61
61
- [ExtensionMethods](./extension-methods.md) replace implicit classes in a way that integrates better with typeclasses.
62
62
- [ImplementingTypeclasses](./typeclasses.md) demonstrates how some common typeclasses can be implemented using the new constructs.
63
63
- [TypeclassDerivation](./derivation.md) introduces constructs to automatically derive typeclass instances forADTs.
64
-
- [MultiversalEquality](./multiversal-equality.md) introduces a special typeclass
65
-
to support typesafe equality.
64
+
- [MultiversalEquality](./multiversal-equality.md) introduces a special typeclass to support typesafe equality.
66
65
- [ImplicitFunctionTypes](./implicit-function-types.md) provide a way to abstract over givenclauses.
67
66
- [ImplicitBy-NameParameters](./implicit-by-name-parameters.md) are an essential tool to define recursive synthesized values without looping.
68
67
- [RelationshipwithScala2Implicits](./relationship-implicits.md) discusses the relationship between old-style implicits and new-style givens and how to migrate from one to the other.
0 commit comments