Merge pull request #170 from pedropark99/dev-epub

Add epub format configs

Author: pedropark99

Chapters/03-structs.qmd

@@ -301,9 +301,22 @@ xsw: switch (@as(u8, 1)) {
 
 ### The `defer` keyword {#sec-defer}
 
-With the `defer` keyword you can register an expression to be executed when you exit the current scope.
-Therefore, this keyword has a similar functionality as the `on.exit()` function from R.
-Take the `foo()` function below as an example. When we execute this `foo()` function, the expression
+Zig has a `defer` keyword, which plays a very important role in control flow, and also, in releasing resources.
+In summary, the `defer` keyword allows you to register an expression to be executed when you exit the current scope.
+
+At this point, you might attempt to compare the Zig `defer` keyword to it's sibling in the Go language
+(i.e. [Go also has a `defer` keyword](https://go.dev/tour/flowcontrol/12)).
+However, the Go `defer` keyword behaves slightly different
+than it's sibling in Zig. More specifically, the `defer` keyword in Go always move an expression to be
+executed at the **exit of the current function**.
+
+If you think deeply about this statement, you will notice that the "exit of the current function" is something
+slightly different than the "exit of the current scope". So, just be careful when comparing the two
+keywords together. A single function in Zig might contain many different scopes inside of it, and, therefore,
+the `defer` input expression might be executed at different places of the function, depending on which scope you
+are currently in.
+
+As a first example, consider the `foo()` function exposed below. When we execute this `foo()` function, the expression
 that prints the message "Exiting function ..." is getting executed only when the function exits
 its scope.
 

Chapters/05-pointers.qmd

@@ -307,7 +307,7 @@ might point to a null value. This is a common source of undefined behaviour in C
 When programmers work with pointers in C, they have to constantly check if
 their pointers are pointing to null values or not.
 
-If for some reason, your Zig code produces a null value somewhere, and, this null
+In contrast, when working in Zig, if for some reason, your Zig code produces a null value somewhere, and, this null
 value ends up in an object that is non-nullable, a runtime error is always
 raised by your Zig program. Take the program below as an example.
 The `zig` compiler can see the `null` value at compile time, and, as result,
@@ -347,8 +347,9 @@ Ok, we know now that all objects are non-nullable by default in Zig.
 But what if we actually need to use an object that might receive a null value?
 Here is where optionals come in.
 
-An optional object in Zig is an object that can be null.
-To mark an object as optional, we use the `?` operator. When you put
+An optional object in Zig is rather similar to a [`std::optional` object in C++](https://en.cppreference.com/w/cpp/utility/optional.html).
+It is an object that can either contain a value, or nothing at all (a.k.a. the object can be null).
+To mark an object in our Zig code as "optional", we use the `?` operator. When you put
 this `?` operator right before the data type of an object, you transform
 this data type into an optional data type, and the object becomes an optional object.