From 5233bd95cb9b8f8f5c608e4a6c6ec21b44385869 Mon Sep 17 00:00:00 2001
From: gkepka <gkepka@virtuslab.com>
Date: Wed, 20 Nov 2024 11:07:57 +0100
Subject: [PATCH] Consistent terminology on type parameters
---
_overviews/core/architecture-of-scala-collections.md | 2 +-
_overviews/parallel-collections/performance.md | 2 +-
_overviews/scala3-book/fun-hofs.md | 2 +-
_overviews/scala3-book/fun-write-map-function.md | 8 ++++----
_overviews/scala3-book/methods-most.md | 4 ++--
_overviews/scala3-book/methods-summary.md | 2 +-
_overviews/scala3-macros/tutorial/quotes.md | 8 ++++----
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/_overviews/core/architecture-of-scala-collections.md b/_overviews/core/architecture-of-scala-collections.md
index 1bc7d82915..74f2bd1b98 100644
--- a/_overviews/core/architecture-of-scala-collections.md
+++ b/_overviews/core/architecture-of-scala-collections.md
@@ -270,7 +270,7 @@ construct another `BitSet` provided the element type of the collection to build
is `Int`. If this is not the case, the compiler will check the superclasses, and
fall back to the implicit builder factory defined in
`mutable.Set`'s companion object. The type of this more general builder
-factory, where `A` is a generic type parameter, is:
+factory, where `A` is a type parameter, is:
CanBuildFrom[Set[_], A, Set[A]]
diff --git a/_overviews/parallel-collections/performance.md b/_overviews/parallel-collections/performance.md
index 96be271b44..2f7aa27f2f 100644
--- a/_overviews/parallel-collections/performance.md
+++ b/_overviews/parallel-collections/performance.md
@@ -45,7 +45,7 @@ garbage collections.
One common cause of a performance deterioration is also boxing and unboxing
that happens implicitly when passing a primitive type as an argument to a
generic method. At runtime, primitive types are converted to objects which
-represent them, so that they could be passed to a method with a generic type
+represent them, so that they could be passed to a method with a type
parameter. This induces extra allocations and is slower, also producing
additional garbage on the heap.
diff --git a/_overviews/scala3-book/fun-hofs.md b/_overviews/scala3-book/fun-hofs.md
index 638c761389..513c520a54 100644
--- a/_overviews/scala3-book/fun-hofs.md
+++ b/_overviews/scala3-book/fun-hofs.md
@@ -61,7 +61,7 @@ p: A => Boolean
{% endtabs %}
means that whatever function you pass in must take the type `A` as an input parameter and return a `Boolean`.
-So if your list is a `List[Int]`, you can replace the generic type `A` with `Int`, and read that signature like this:
+So if your list is a `List[Int]`, you can replace the type parameter `A` with `Int`, and read that signature like this:
{% tabs filter-definition_2 %}
{% tab 'Scala 2 and 3' %}
diff --git a/_overviews/scala3-book/fun-write-map-function.md b/_overviews/scala3-book/fun-write-map-function.md
index 02ee9abf75..9799c97d52 100644
--- a/_overviews/scala3-book/fun-write-map-function.md
+++ b/_overviews/scala3-book/fun-write-map-function.md
@@ -18,7 +18,7 @@ Focusing only on a `List[Int]`, you state:
> I want to write a `map` method that can be used to apply a function to each element in a `List[Int]` that it’s given, returning the transformed elements as a new list.
Given that statement, you start to write the method signature.
-First, you know that you want to accept a function as a parameter, and that function should transform an `Int` into some generic type `A`, so you write:
+First, you know that you want to accept a function as a parameter, and that function should transform an `Int` into some type `A`, so you write:
{% tabs map-accept-func-definition %}
{% tab 'Scala 2 and 3' %}
@@ -28,7 +28,7 @@ def map(f: (Int) => A)
{% endtab %}
{% endtabs %}
-The syntax for using a generic type requires declaring that type symbol before the parameter list, so you add that:
+The syntax for using a type parameter requires declaring it in square brackets `[]` before the parameter list, so you add that:
{% tabs map-type-symbol-definition %}
{% tab 'Scala 2 and 3' %}
@@ -48,7 +48,7 @@ def map[A](f: (Int) => A, xs: List[Int])
{% endtab %}
{% endtabs %}
-Finally, you also know that `map` returns a transformed `List` that contains elements of the generic type `A`:
+Finally, you also know that `map` returns a transformed `List` that contains elements of the type `A`:
{% tabs map-with-return-type-definition %}
{% tab 'Scala 2 and 3' %}
@@ -98,7 +98,7 @@ def map[A](f: (Int) => A, xs: List[Int]): List[A] =
### Make it generic
As a bonus, notice that the `for` expression doesn’t do anything that depends on the type inside the `List` being `Int`.
-Therefore, you can replace `Int` in the type signature with the generic type parameter `B`:
+Therefore, you can replace `Int` in the type signature with the type parameter `B`:
{% tabs map-function-full-generic class=tabs-scala-version %}
{% tab 'Scala 2' %}
diff --git a/_overviews/scala3-book/methods-most.md b/_overviews/scala3-book/methods-most.md
index 8af9552e6a..2a282cdf28 100644
--- a/_overviews/scala3-book/methods-most.md
+++ b/_overviews/scala3-book/methods-most.md
@@ -14,7 +14,7 @@ This section introduces the various aspects of how to define and call methods in
Scala methods have many features, including these:
-- Generic (type) parameters
+- Type parameters
- Default parameter values
- Multiple parameter groups
- Context-provided parameters
@@ -690,7 +690,7 @@ There’s even more to know about methods, including how to:
- Handle exceptions
- Use vararg input parameters
- Write methods that have multiple parameter groups (partially-applied functions)
-- Create methods that have generic type parameters
+- Create methods that have type parameters
{% comment %}
Jamie: there really needs better linking here - previously it was to the Scala 3 Reference, which doesnt cover any
diff --git a/_overviews/scala3-book/methods-summary.md b/_overviews/scala3-book/methods-summary.md
index 8d36108654..eafac85889 100644
--- a/_overviews/scala3-book/methods-summary.md
+++ b/_overviews/scala3-book/methods-summary.md
@@ -18,7 +18,7 @@ There’s even more to know about methods, including how to:
- Handle exceptions
- Use vararg input parameters
- Write methods that have multiple parameter groups (partially-applied functions)
-- Create methods that have generic type parameters
+- Create methods that have type parameters
See the [Reference documentation][reference] for more details on these features.
diff --git a/_overviews/scala3-macros/tutorial/quotes.md b/_overviews/scala3-macros/tutorial/quotes.md
index be34958958..e5862b3d9b 100644
--- a/_overviews/scala3-macros/tutorial/quotes.md
+++ b/_overviews/scala3-macros/tutorial/quotes.md
@@ -250,21 +250,21 @@ case ...
### Matching types
So far, we assumed that the types within quote patterns would be statically known.
-Quote patterns also allow for generic types and existential types, which we will see in this section.
+Quote patterns also allow for type parameters, which we will see in this section.
-#### Generic types in patterns
+#### Type parameters in patterns
Consider the function `exprOfOption` that we have already seen:
```scala
def exprOfOption[T: Type](x: Expr[Option[T]])(using Quotes): Option[Expr[T]] =
x match
case '{ Some($x: T) } => Some(x) // x: Expr[T]
- // ^^^ type ascription with generic type T
+ // ^^^ type ascription with type T
...
```
Note that this time we have added the `T` explicitly in the pattern, even though it could be inferred.
-By referring to the generic type `T` in the pattern, we are required to have a given `Type[T]` in scope.
+By referring to the type parameter `T` in the pattern, we are required to have a given `Type[T]` in scope.
This implies that `$x: T` will only match if `x` is of type `Expr[T]`.
In this particular case, this condition will always be true.