From fdd1d92f8c6147bf8bc09046383da829d183b897 Mon Sep 17 00:00:00 2001
From: JirCep <uzivatel919@seznam.cz>
Date: Sat, 1 Oct 2022 21:45:04 +0200
Subject: [PATCH 1/3] Type parameter removal

`Vec<T>` denotes generic type. As this chapter kindly describes Rust generics cannot hold 2 or more struct kinds.
---
 src/ch17-02-trait-objects.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/ch17-02-trait-objects.md b/src/ch17-02-trait-objects.md
index 2d3fea24a1..bb43cc6763 100644
--- a/src/ch17-02-trait-objects.md
+++ b/src/ch17-02-trait-objects.md
@@ -124,7 +124,7 @@ collections, using generics and trait bounds is preferable because the
 definitions will be monomorphized at compile time to use the concrete types.
 
 On the other hand, with the method using trait objects, one `Screen` instance
-can hold a `Vec<T>` that contains a `Box<Button>` as well as a
+can hold a `Vec` that contains a `Box<Button>` as well as a
 `Box<TextField>`. Let’s look at how this works, and then we’ll talk about the
 runtime performance implications.
 

From 8a33c9495a4dd9e5f6cc77b19ad06f0cdb87684b Mon Sep 17 00:00:00 2001
From: JirCep <uzivatel919@seznam.cz>
Date: Sat, 1 Oct 2022 22:51:08 +0200
Subject: [PATCH 2/3] Trait bounds are discussed later

Beside trait bounds are discussed in 10.2 not in 10.1, _monomorphization_ relates to generics in general not only those bound by/to trait.
---
 src/ch17-02-trait-objects.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/ch17-02-trait-objects.md b/src/ch17-02-trait-objects.md
index bb43cc6763..328d58d81f 100644
--- a/src/ch17-02-trait-objects.md
+++ b/src/ch17-02-trait-objects.md
@@ -232,14 +232,14 @@ didn’t mean to pass and so should pass a different type or we should implement
 Recall in the [“Performance of Code Using
 Generics”][performance-of-code-using-generics]<!-- ignore --> section in
 Chapter 10 our discussion on the monomorphization process performed by the
-compiler when we use trait bounds on generics: the compiler generates
-nongeneric implementations of functions and methods for each concrete type that
-we use in place of a generic type parameter. The code that results from
-monomorphization is doing *static dispatch*, which is when the compiler knows
-what method you’re calling at compile time. This is opposed to *dynamic
-dispatch*, which is when the compiler can’t tell at compile time which method
-you’re calling. In dynamic dispatch cases, the compiler emits code that at
-runtime will figure out which method to call.
+compiler on generics: the compiler generates nongeneric implementations 
+of functions and methods for each concrete type that we use in place of 
+a generic type parameter. The code that results from monomorphization is
+doing *static dispatch*, which is when the compiler knows what method you’re
+calling at compile time. This is opposed to *dynamic dispatch*, which is
+when the compiler can’t tell at compile time which method you’re calling.
+In dynamic dispatch cases, the compiler emits code that at runtime will 
+figure out which method to call.
 
 When we use trait objects, Rust must use dynamic dispatch. The compiler doesn’t
 know all the types that might be used with the code that’s using trait objects,

From f2fc3f0e2680fafd3c39a188b2daa73e7b84436d Mon Sep 17 00:00:00 2001
From: JirCep <uzivatel919@seznam.cz>
Date: Fri, 21 Oct 2022 21:24:10 +0200
Subject: [PATCH 3/3] `Vec<T>` return

---
 src/ch17-02-trait-objects.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/ch17-02-trait-objects.md b/src/ch17-02-trait-objects.md
index 328d58d81f..a3316e0174 100644
--- a/src/ch17-02-trait-objects.md
+++ b/src/ch17-02-trait-objects.md
@@ -124,7 +124,7 @@ collections, using generics and trait bounds is preferable because the
 definitions will be monomorphized at compile time to use the concrete types.
 
 On the other hand, with the method using trait objects, one `Screen` instance
-can hold a `Vec` that contains a `Box<Button>` as well as a
+can hold a `Vec<T>` that contains a `Box<Button>` as well as a
 `Box<TextField>`. Let’s look at how this works, and then we’ll talk about the
 runtime performance implications.