Consistent terminology on type parameters

Author: gkepka

_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]]
 

_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.
 

_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' %}

_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' %}

_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

_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.
 

_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.