diff --git a/_overviews/core/architecture-of-scala-collections.md b/_overviews/core/architecture-of-scala-collections.md index 1bc7d8291..74f2bd1b9 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 96be271b4..2f7aa27f2 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 638c76138..513c520a5 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 02ee9abf7..9799c97d5 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 8af9552e6..2a282cdf2 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 8d3610865..eafac8588 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 be3495895..e5862b3d9 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.