Merge pull request #73 from kurz-m/makurz-contribute

some minor typo fixes in 03-structs.qmd

Chapters/03-structs.qmd

@@ -722,7 +722,7 @@ But also notice that every line in the struct body that describes a data member,
 So every time you declare a data member in your Zig code, always end the line with a comma character, instead
 of ending it with the traditional semicolon character (`;`).
 
-Next, also notice in this example, that we have registrated an `init()` function as a method
+Next, we have registered an `init()` function as a method
 of this `User` struct. This `init()` method is the constructor method that we will use to instantiate
 every new `User` object. That is why this `init()` function returns a new `User` object as result.
 
@@ -804,7 +804,7 @@ In essence, the `zig` compiler will look for some hint of what is the type of th
 This hint can be the type annotation of a function argument,
 or the return type annotation of the function that you are using, or the type annotation
 of an existing object.
-If the compiler do find such type annotation, then, it will use this
+If the compiler does find such type annotation, it will use this
 type in your literal struct.
 
 Anonymous structs are very common to be used as inputs to function arguments in Zig.
@@ -857,14 +857,14 @@ const Vec3 = struct {
 ### The `self` method argument {#sec-self-arg}
 
 In every language that have OOP, when we declare a method of some class or struct, we
-usually declare this method as a function that have a `self` argument.
+usually declare this method as a function that has a `self` argument.
 This `self` argument is the reference to the object itself from which the method
 is being called from.
 
 It is not mandatory to use this `self` argument. But why would you not use this `self` argument?
 There is no reason to not use it. Because the only way to get access to the data stored in the
 data members of your struct is to access them through this `self` argument.
-If you don't need to use the data in the data members of your struct inside your method, then, you very likely don't need
+If you don't need to use the data in the data members of your struct inside your method, you very likely don't need
 a method. You can just declare this logic as a simple function, outside of your
 struct declaration.
 
@@ -939,12 +939,12 @@ As a result of that, when we create `Vec3` objects we usually create them as
 constant objects, like the `v1` and `v2` objects presented in @sec-self-arg.
 We can create them as variable objects with the `var` keyword,
 if we want to. But because the methods of this `Vec3` struct do not change
-the state of the objects in any point, is unnecessary to mark them
+the state of the objects in any point, it's unnecessary to mark them
 as variable objects.
 
-But why? Why am I talkin about this here? Is because the `self` argument
+But why? Why am I talking about this here? It's because the `self` argument
 in the methods is affected depending on whether the
-methods present in a struct change or not the state of the object itself.
+methods present in a struct change or don't change the state of the object itself.
 More specifically, when you have a method in a struct that changes the state
 of the object (i.e. change the value of a data member), the `self` argument
 in this method must be annotated in a different manner.
@@ -997,8 +997,8 @@ const Vec3 = struct {
 ```
 
 Notice in the code example above that we have added a new method
-to our `Vec3` struct named `double()`. This method essentially doubles the
-coordinate values of our vector object. Also notice that, in the
+to our `Vec3` struct named `double()`. This method doubles the
+coordinate values of our vector object. In the
 case of the `double()` method, we annotated the `self` argument as `*Vec3`,
 indicating that this argument receives a pointer (or a reference, if you prefer to call it this way)
 to a `Vec3` object as input.
@@ -1020,7 +1020,7 @@ Doubled: 8.4
 
 Now, if you change the `self` argument in this `double()` method to `self: Vec3`, like in the
 `distance()` method, you will get the compiler error exposed below as result. Notice that this
-error message is indicating a line from the `double()` method body,
+error message is showing a line from the `double()` method body,
 indicating that you cannot alter the value of the `x` data member.
 
 ```{zig}
@@ -1043,15 +1043,14 @@ If you take some time, and think hard about this error message, you will underst
 You already have the tools to understand why we are getting this error message.
 We have talked about it already in @sec-fun-pars.
 So remember, every function argument is immutable in Zig, and `self`
-is included in this rule.
+is no exception to this rule.
 
-It does not matter if the object that you pass as input to the function argument is
-a variable object or not. In this example, we marked the `v3` object as a variable object.
+In this example, we marked the `v3` object as a variable object.
 But this does not matter. Because it is not about the input object, it is about
 the function argument.
 
 The problem begins when we try to alter the value of `self` directly, which is a function argument,
-and, every function argument is immutable by default. You may quest yourself how can we overcome
+and, every function argument is immutable by default. You may ask yourself how can we overcome
 this barrier, and once again, the solution was also discussed in @sec-fun-pars.
 We overcome this barrier, by explicitly marking the `self` argument as a pointer.
 
@@ -1083,17 +1082,17 @@ as input.
 In general, type inference in Zig is done by using the dot character (`.`).
 Everytime you see a dot character written before a struct literal, or before an enum value, or something like that,
 you know that this dot character is playing a special party in this place. More specifically, it is
-telling the `zig` compiler something on the lines of: "Hey! Can you infer the type of this
-value for me? Please!". In other words, this dot character is playing a role similar to the `auto` keyword in C++.
+telling the `zig` compiler something along the lines of: "Hey! Can you infer the type of this
+value for me? Please!". In other words, this dot character is playing a similar role as the `auto` keyword in C++.
 
-I give you some examples of this in @sec-anonymous-struct-literals, where we present anonymous struct literals.
-Anonymous struct literals are, essentially, struct literals that use type inference to
+I gave you some examples of this in @sec-anonymous-struct-literals, where we used anonymous struct literals.
+Anonymous struct literals are, struct literals that use type inference to
 infer the exact type of this particular struct literal.
 This type inference is done by looking for some minimal hint of the correct data type to be used.
 You could say that the `zig` compiler looks for any neighbouring type annotation that might tell him
 what would be the correct type.
 
-Another common place where we use type inference in Zig is at switch statements (which we talk about in @sec-switch).
+Another common place where we use type inference in Zig is at switch statements (which we talked about in @sec-switch).
 I also gave some other examples of type inference in @sec-switch, where we were inferring the data types of enum values listed inside
 of switch statements (e.g. `.DE`).
 But as another example, take a look at this `fence()` function reproduced below,
@@ -1103,14 +1102,14 @@ of the Zig Standard Library.
 [^fence-fn]: <https://github.com/ziglang/zig/blob/master/lib/std/atomic.zig>.
 
 There are a lot of things in this function that we haven't talked about yet, such as:
-what `comptime` means? `inline`? `extern`? What is this star symbol before `Self`?
+what `comptime` means? `inline`? `extern`?
 Let's just ignore all of these things, and focus solely on the switch statement
 that is inside this function.
 
 We can see that this switch statement uses the `order` object as input. This `order`
 object is one of the inputs of this `fence()` function, and we can see in the type annotation,
 that this object is of type `AtomicOrder`. We can also see a bunch of values inside the
-switch statements that begins with a dot character, such as `.release` and `.acquire`.
+switch statements that begin with a dot character, such as `.release` and `.acquire`.
 
 Because these weird values contain a dot character before them, we are asking the `zig`
 compiler to infer the types of these values inside the switch statement. Then, the `zig`