rust.tex

\documentclass{beamer}
%\usepackage[utf8]{inputenc}
\usepackage{textcomp}
%\usepackage{graphicx}
%\usepackage {mathtools}
%\usepackage{utopia} %font utopia imported
\usetheme{CambridgeUS}
%\usecolortheme{default}
\usepackage{minted}
%\usefonttheme{professionalfonts}
%\usepackage{natbib}
%\usepackage{hyperref}
\usepackage{colortbl}
\usepackage{pifont} % Custom bullets
%------------------------------------------------------------
% set colors
\definecolor{greyColor}{RGB}{242,242,245} % grey
\definecolor{greenColor}{RGB}{51,112,98} % green
\definecolor{yellowColor}{RGB}{246,202,84} % yellow
\definecolor{blackColor}{RGB}{84,84,84} % yellow
%------------------------------------------------------------
\setbeamercolor*{palette primary}{bg=yellowColor}
\setbeamercolor*{palette secondary}{bg=greyColor}
\setbeamercolor*{palette tertiary}{bg=greenColor, fg = white}
\setbeamercolor*{titlelike}{fg=greyColor}
\setbeamercolor*{title}{bg=greenColor, fg = white}
\setbeamercolor*{item}{fg=blackColor}
\setbeamercolor*{caption}{fg=greenColor}
\setbeamercolor{frametitle}{fg=black,bg=greyColor}

% customize the caption
\setbeamerfont{caption}{size=\footnotesize}
\setbeamercolor{caption}{fg=blackColor}
\setbeamercolor{caption name}{fg=greenColor}

% https://latex-beamer.com/tutorials/blocks/
\setbeamertemplate{blocks}[rounded][shadow=true]
\setbeamercolor{block title}{bg=greenColor, fg=white}
\setbeamercolor{block body}{bg=greyColor, fg=blackColor}

% see https://pygments.org/styles/
\usemintedstyle{solarized-light}
% [bgcolor=greyColor,linenos, breaklines,frame=leftline, numbersep=1pt,mathescape]
\setminted[shell]{bgcolor=greyColor, breaklines, numbersep=1pt,mathescape, fontsize=\footnotesize}
\setminted[rust]{bgcolor=greyColor,linenos, breaklines,frame=leftline, numbersep=1pt,mathescape, fontsize=\footnotesize}
\setminted[toml]{bgcolor=greyColor,linenos, breaklines,frame=leftline, numbersep=1pt,mathescape, fontsize=\footnotesize}
%------------------------------------------------------------
\title[Rust-Lang]{Rust Programming Language}
\author[Yumcoder]{Yumcoder}

\institute[UoT]{University of Toronto}
\date[December 1, 2022]
{ \tiny Updated At: \small \today}
%------------------------------------------------------------
%This block of commands puts the table of contents at the 
%beginning of each section and highlights the current section:
%\AtBeginSection[]
%{
	%  \begin{frame}
		%    \frametitle{Contents}
		%    \tableofcontents[currentsection]
		%  \end{frame}
	%}
\AtBeginSection[]{
	\begin{frame}
		\vfill
		\centering
		\begin{beamercolorbox}[sep=8pt,center,shadow=true,rounded=true]{title}
			\usebeamerfont{title}\insertsectionhead\par%
		\end{beamercolorbox}
		\vfill
	\end{frame}
}
%------------------------------------------------------------

\begin{document}
	
	%The next statement creates the title page.
	\frame{\titlepage}
	\begin{frame}
		\frametitle{Contents}
		\mbox{
			\linespread{2.3}
			\tiny
			\begin{columns}
				\column{0.5\textwidth}
				\tableofcontents[sections = 1-10]
				\column{0.5\textwidth}
				\tableofcontents[sections = 11-20]
			\end{columns}
		}
	\end{frame}
	%------------------------------------------------------------
	\section{Introduction}
	\begin{frame}[fragile]
		\frametitle{Installing rustup on Linux or macOS}
		If you’re using Linux or macOS, open a terminal and enter the following command:
		
		\inputminted{shell}{./code/install.shell}
		If the install is successful, the following line will appear:
		\begin{minted}[linenos=false, breaklines,frame=none]{shell}
			Rust is installed now. Great!
		\end{minted}
		To check whether you have Rust installed correctly, open a shell and enter this line:
		\inputminted{shell}{./code/install-check.shell}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Updating, Uninstalling and Local Documentation}
		Once Rust is installed via rustup, when a new version of Rust is released, updating to the latest version is easy. From your shell, run the following update script:
		
		\inputminted{shell}{./code/install-update.shell}
		
		To uninstall Rust and rustup, run the following uninstall script from your shell:
		\inputminted{shell}{./code/install-uninstall.shell}
		
		The installation of Rust also includes a local copy of the documentation, so you can read it offline. Run \mintinline{shell}{rustup doc}  to open the local documentation in your browser.
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Hello, World!}
		Open a terminal and enter the following commands:
		
		\inputminted[linenos, breaklines,frame=leftline, numbersep=1pt]{shell}{./code/hello-world.shell}
		
		Make a new source file and save it as main.rs:
		\inputminted{rust}{./code/hello-world-main.rs}
		
		Compile and run the file:
		\inputminted{shell}{./code/hello-world-compile.shell}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Cargo}
		\begin{itemize}
			\item Cargo is \textbf{Rust’s build system and package manager}. 
			\item Most \textbf{Rustaceans} use this tool to manage their Rust projects because Cargo handles a lot of tasks for you, such as building your code, downloading the libraries your code depends on, and building those libraries. 
			\begin{itemize}
				\item[\ding{43}] \textbf{Rustaceans} are people who use Rust, contribute to Rust, or are interested in the development of Rust.
			\end{itemize}
			\item  Cargo comes installed with Rust if you used the official installer.
			\begin{itemize}
				\item[] \inputminted{shell}{./code/cargo.shell}
			\end{itemize}
		\end{itemize}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Hello, Cargo!}
		Creating a Project with Cargo:
		\inputminted{shell}{./code/hello-cargo.shell}
		
		\begin{figure}
			\centering
			\includegraphics[width=0.65\textwidth]{./img/rust-project-folder-structure.png}
			\caption{Folder structure for projects in rust programming language.}
			\label{fig:folderRustLang}
		\end{figure}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Cargo.toml}
		This file is in the \textbf{TOML} (Tom’s Obvious, Minimal Language) format, which is \textbf{Cargo’s configuration} format.
		
		\inputminted{toml}{./code/cargo.toml}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Building and Running a Cargo Project}
		Now open src/main.rs and take a look:
		\inputminted{rust}{./code/hello-world-main.rs}
		
		Build your project by entering the following command:
		
		\inputminted{shell}{./code/hello-world-build.shell}
		
		\begin{itemize}
			\item Use \mintinline{shell}{cargo run} to compile and then run (all in one command).
			\item When your project is finally ready for release, you can use \mintinline{shell}{cargo build --release} to compile it with optimizations (create an executable in target/release instead of target/debug). 
		\end{itemize}
	\end{frame}
	
	\section{Common Programming Concepts}
	
	\begin{frame}{Variables and Mutability}
		\begin{itemize}
			\item by default variables are \textbf{immutable}. 
			\item This is one of many \textbf{\href{https://en.wikipedia.org/wiki/Nudge_theory}{\underline{nudges}} Rust}   gives you to write your code in a way that takes advantage of the \textbf{safety and easy concurrency }that Rust offers. 
			\begin{itemize}
				\item However, you still have the option to make your variables \textbf{mutable}. 
			\end{itemize}
		\end{itemize}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Immutable variables}
		When a variable is immutable, \textit{once a value is bound to a name, you can’t change that value.}
		
		\inputminted{rust}{./code/immutable-variable.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Immutable variables (2)}
		You should receive an error message, as shown in this output:
		
		\inputminted{shell}{./code/immutable-variable.shell}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Mutable variables}
		Although variables are immutable by default, you can make them mutable by adding \mintinline{rust}{mut} in front of the variable name.
		
		\inputminted{rust}{./code/mutable-variable.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Mutable variables (2)}
		\inputminted{shell}{./code/mutable-variable.shell}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Constants}
		Rust’s naming convention for constants is to use \textit{all uppercase with underscores between words}.
		\inputminted[linenos=false, frame=none]{rust}{./code/const.rs}
		Like immutable variables, constants are values that are bound to a name and are not allowed to change, but there are a few differences between constants and variables.
		
		\begin{itemize}
			\item you aren’t allowed to use \mintinline{rust}{mut} with constants. Constants aren’t just immutable by default—\textbf{they’re always immutable}. You declare constants using the const keyword instead of the let keyword, and \textbf{the type of the value must be annotated}.
			
			\item 		constants may be set only to a constant expression, \textbf{not the result of a value that could only be computed at runtime}.
		\end{itemize}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Shadowings}
		Rustaceans say that the first variable is shadowed by the second, which means that the second variable is what the compiler will see when you use the name of the variable.  We can shadow a variable by using the same variable’s name and repeating the use of the \mintinline{rust}{let} keyword as follows
		
		\inputminted{rust}{./code/shadowing.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Shadowing (2)}
		\inputminted{shell}{./code/shadowing.shell}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Shadowing vs Mutable variables}
		
		We’re effectively creating a new variable when we use the let keyword again, we can change the type of the value but reuse the same name.
		
		\begin{columns}
			\column{0.5\textwidth}
			\inputminted{rust}{./code/shadowing-vs-mutable-var1.rs}
			The first spaces variable is a string type and the second spaces variable is a number type. 
			\column{0.5\textwidth}
			\inputminted{rust}{./code/shadowing-vs-mutable-var2.rs}
			we’ll get a \textbf{compile-time error}: mismatched types, expected `\&str`, found `usize`.
		\end{columns}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Data Types - Primitive type}
		\begin{columns}
			\column{0.5\textwidth}
			Data type subsets: 
			\begin{itemize}
				\item Scalar
				\begin{itemize}
					\item Integers
					\item Floating-point numbers
					\item Booleans
					\item Characters
				\end{itemize}
				\item Compound
				\begin{itemize}
					\item Tuples 
					\item Arrays
				\end{itemize}
			\end{itemize}
			\column{0.5\textwidth}
			\inputminted{rust}{./code/data-types.rs}
		\end{columns}
		
		\begin{block}{Statically typed language}
			Keep in mind that Rust is a statically typed language, which means that \textbf{it must know the types of all variables at compile time}. 
		\end{block}
		
		The compiler can usually \textbf{infer} what type we want to use based on the value and how we use it (example: \mintinline{rust}{let x = 2.0; // f64}).
		
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Integer Types}
		\begin{itemize}
			\item An integer is a number without a fractional component.
			\item This type declaration indicates that the value it’s associated with should be an unsigned integer (signed integer types start with \textbf{i}, instead of \textbf{u}) that takes up 32 bits of space.
		\end{itemize}
		
		\begin{table}
			\begin{tabular}{|c|c|c|}
				\hline
				\rowcolor{greyColor}
				Length & Signed & Unsigned \\
				\hline
				8-bit & i8 & u8 \\
				16-bit & i16 & u16 \\
				32-bit & i32 & u32 \\
				64-bit & i64 & u64 \\
				128-bit & i128 & u128 \\
				arch\footnote{the isize and usize types depend on the architecture: 64 bits if you’re on a 64-bit architecture and 32 bits if you’re on a 32-bit architecture.} & isize & usize \\
				\hline
			\end{tabular}
		\end{table}
		
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Integer literals}
		\begin{itemize}
			\item A number literal is a type suffix, such as \mintinline{rust}{57u8}, to designate the type
			\item Number literals can also use \mintinline{rust}{_} as a visual separator to make the number easier to read, such as  \mintinline{rust}{1_000} , which will have the same value as if you had specified \mintinline{rust}{1000}
		\end{itemize}
		\begin{table}
			\begin{tabular}{|c|c|}
				\hline
				\rowcolor{greyColor}
				Number literals	& Example \\
				\hline
				Decimal & \mintinline{rust}{let x = 98_222} \\
				Hex & \mintinline{rust}{let x = 0xff} \\
				Octal & \mintinline{rust}{let x = 0o77} \\
				Binary & \mintinline{rust}{let x = 0b1111_0000} \\
				Byte (u8 only) & \mintinline{rust}{let x = b'A'} \\
				\hline
			\end{tabular}
		\end{table}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Integer Overflow}
		\begin{itemize}
			\item Let’s say you have a variable of type u8 that can hold values between 0 and 255. 
			\item 		If you try to change the variable to a value outside of that range, such as 256, integer overflow will occur, which can result in one of two behaviors:
			\begin{itemize}
				\item When you’re compiling in \textbf{debug mode}, Rust includes checks for integer overflow that cause your program to panic at runtime if this behavior occurs.
				\item 		When you’re compiling in \textbf{release mode} with the --release flag, Rust does not include checks for integer overflow that cause panics (In the case of a u8, the value 256 becomes 0, the value 257 becomes 1, and so on).
			\end{itemize}
		\end{itemize}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Floating-Point Types}
		\begin{itemize}
			
			\item Rust’s floating-point types are f32 (32 bits) and f64(64 bits), see (\href{https://en.wikipedia.org/wiki/IEEE_754}{\textsc{IEEE-754 standard}}).
			
			\item The default type is f64 because on modern CPUs it’s roughly the same speed as f32 but is capable of more precision. 
			\item All floating-point types are signed.
		\end{itemize}
		\begin{columns}
			\column{0.5\textwidth}
			\inputminted{rust}{./code/floating-types.rs}
			\column{0.5\textwidth}
			\inputminted{rust}{./code/IEEE-754.rs}
		\end{columns}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Numeric Operations}
		\inputminted{rust}{./code/numeric-operations.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Boolean Types}
		Booleans are one byte in size.
		
		\inputminted{rust}{./code/bool-types.rs}
	\end{frame}
	
	
	\begin{frame}[fragile]
		\frametitle{Character Types}
		\begin{itemize}
			\item Note that we specify char literals with \textbf{single quotes}, as opposed to string literals, which use double quotes. 
			\item \textbf{Rust’s char type is four bytes in size} and represents a Unicode Scalar Value, which means it can represent a lot more than just ASCII.
		\end{itemize}
		\begin{figure}
			\centering
			\includegraphics[width=0.65\textwidth]{./img/char.png}
		\end{figure}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Tuple Types}
		A tuple is a general way of grouping together a number of values with a variety of types into one \textbf{compound type}.
		
		\inputminted{rust}{./code/tuple-types.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Array Types}
		\begin{itemize}
			\item Another way to have a collection of multiple values is with an array. 
			\item Unlike a tuple, every element of \textbf{an array must have the same type}. 
			\item Unlike arrays in some other languages, \textbf{arrays in Rust have a fixed length}.
			\item \textbf{Rust panics if index out of bounds}.
		\end{itemize}
		\begin{block}{Note}
			Arrays are useful when you want your data allocated on the \textbf{stack} rather than the \textbf{heap} 
		\end{block}
		
		%\inputminted{rust}{./code/tuple-types.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Array Types (2)}
		
		\inputminted{rust}{./code/array.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Functions}
		Rust code uses \textbf{snake case} as the conventional style for function and variable names, in which all letters are lowercase and underscores separate words.
		
		\inputminted{rust}{./code/function.rs}
		
		\tiny
		functions \textbf{parameters} are special variables that are part of a function’s signature. When a function has parameters, you can provide it with concrete values for those parameters. Technically, the concrete values are called \textbf{arguments}, but in casual conversation, people tend to use the words parameter and argument interchangeably.
		
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Statements vs Expressions}
		\begin{columns}
			\column{0.4\textwidth}
			\begin{block}{Statements}
				are instructions that perform some action and do not return a value.
			\end{block}
			\column{0.5\textwidth}
			\begin{block}{Expressions}
				evaluate to a resulting value.
			\end{block}
		\end{columns}
		\inputminted{rust}{./code/statements-expressions.rs}
	\end{frame}
	
	
	\begin{frame}[fragile]
		\frametitle{Functions with Return Values}
		\begin{itemize}
			\item Function bodies are made up of a series of statements optionally ending in an expression.
			\item Calling a function is an expression.
			\item Functions can return values to the code that calls them. 
			\item We don’t name return values, but we must declare their type after an arrow (\mintinline{rust}| ->|). 
			\item In Rust, the \textbf{return value of the function} is synonymous with \textbf{the value of the final expression in the block of the body} of a function. 
			\item You can return early from a function by using the return keyword and specifying a value, but most functions return the last expression implicitly.
		\end{itemize}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Functions with Return Values (2)}
		\inputminted{rust}{./code/function-return.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Functions with Return Values (3)}
		\inputminted{rust}{./code/function-return2.rs}
		
		The definition of the function \mintinline{rust}|plus_one|  says that it will return an \mintinline{rust}|i32| , but statements don’t evaluate to a value, which is expressed by \mintinline{rust}|()|, the unit type.
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Functions with Return Values (4)}
		\inputminted{shell}{./code/function-return3.shell}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{if Expressions}
		if expressions are sometimes called arms
		\inputminted{rust}{./code/if.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{if Expressions (2)}
		It’s also worth noting that the condition in this code must be a bool. If the condition isn’t a bool, we’ll get an error.
		\begin{columns}
			\column{0.5\textwidth}
			\inputminted{rust}{./code/if-err.rs}
			
			\column{0.5\textwidth}
			\inputminted{rust}{./code/if-err-correct.rs}
		\end{columns}
		\inputminted{shell}{./code/if-err.shell}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Using if in a let Statement}
		Remember that blocks of code evaluate to the last expression in them, and numbers by themselves are also expressions
		\inputminted{rust}{./code/if-let.rs}
		
		The results of both the if arm and the else arm should be in the same type. So, \mintinline{rust}|let number = if condition { 5 } else { "six" };| get panic error.
	\end{frame}
	
	
	\begin{frame}[fragile]
		\frametitle{Repetition with Loops}
		The loop keyword tells Rust to execute a block of code over and over again forever or until you explicitly tell it to stop.
		\inputminted{rust}{./code/loop.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Returning Values from Loops}
		\inputminted{rust}{./code/loop-return.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Loop Labels to Disambiguate Between Multiple Loops}
		Loop labels must begin with a single quote
		\scriptsize
		\inputminted{rust}{./code/loop-label.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Conditional Loops with while}
		\inputminted{rust}{./code/while.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Repetition with for}
		\inputminted{rust}{./code/for.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{for with range}
		\inputminted{rust}{./code/for-range.rs}
	\end{frame}
	
	\section{Understanding Ownership}
	
	\begin{frame}[fragile]
		\frametitle{What Is Ownership?}
		\begin{itemize}
			\item \textbf{Ownership} is a set of rules that governs how a Rust program manages memory.
			\item 		Some languages have \textbf{garbage collection} that \textbf{regularly looks} (performance?) for no-longer used memory as the program runs;
			\item 		 In other languages, the \textbf{programmer} must \textbf{explicitly allocate and free} the memory.
			\item 		 Rust uses a third approach: memory is managed through a system of ownership with \textbf{a set of rules} that the\textbf{ compiler checks}. If any of the rules are violated, the program won’t compile.
		\end{itemize}
		\begin{block}{Note}
			None of the features of ownership will slow down your program while it’s running.
		\end{block}
		\tiny Because ownership is a new concept for many programmers, it does take some time to get used to.
	\end{frame}
	
	
	\begin{frame}[fragile]
		\frametitle{The Stack and the Heap}
		\begin{itemize}
			\item In a systems programming language like Rust, whether a value is on the stack or the heap affects how the language behaves and why you have to make certain decisions. Parts of ownership will be described in relation to the stack and the heap later in the following, so here is a brief explanation.
			\item 	Both the \textbf{stack and the heap} are \textbf{parts of memory} available to your code to use at runtime, but they are structured in different ways. 
			\item The \textbf{stack} stores values in the order it gets them and removes the values in the opposite order. This is \textbf{referred to as last in, first out}. Adding data is called pushing onto the stack, and removing data is called popping off the stack. \textbf{All data stored on the stack must have a known, fixed size}. Data with an unknown size at compile time or a size that might change must be stored on the heap instead.
		\end{itemize}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{The Stack and the Heap (2)}
		\begin{itemize}
			\item 	The heap is less organized: when you put data on the heap, you request a certain amount of space. The \textbf{memory allocator} finds an empty spot in the heap that is big enough, marks it as being in use, and returns a pointer, which is the address of that location. This process is called allocating on the heap and is sometimes abbreviated as just allocating (pushing values onto the stack is not considered allocating). \textbf{Because the pointer to the heap is a known, fixed size, you can store the pointer on the stack, but when you want the actual data, you must follow the pointer}.
			\item 	\textbf{Pushing to the stack is faster than allocating on the heap} because the allocator never has to search for a place to store new data; that location is always at the top of the stack. Comparatively, allocating space on the heap requires more work, because the allocator must first find a big enough space to hold the data and then perform bookkeeping to prepare for the next allocation.
			
		\end{itemize}
	\end{frame}
	
	
	
	\begin{frame}[fragile]
		\frametitle{The Stack and the Heap (3)}
		\begin{itemize}
			\item 	When your code calls a function, the values passed into the function (including, potentially, pointers to data on the heap) and the function’s local variables get pushed onto the stack. When the function is over, those values get popped off the stack.
			\item 	Keeping track of what parts of code are using what data on the heap, minimizing the amount of duplicate data on the heap, and cleaning up unused data on the heap so you don’t run out of space are all problems that ownership addresses. Once you understand ownership, you won’t need to think about the stack and the heap very often, but knowing that the main purpose of ownership is to manage heap data can help explain why it works the way it does.
		\end{itemize}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Ownership Rules}
		\begin{itemize}
			\item Each value in Rust has an owner.
			\item There can only be one owner at a time.
			\item When the owner goes out of scope, the value will be dropped.
		\end{itemize}
		
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{Variable Scope}
		\inputminted{rust}{./code/scope.rs}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{The String Type}
		\begin{itemize}
			\item To illustrate the rules of ownership, we need a data type that is more complex than those we covered in the “Data Types” section
			\item The types covered previously are all a\textbf{ known size}, can be \textbf{stored on the stack and popped off the stack when their scope is over}, and can be quickly and trivially copied to make a new, independent instance if another part of code needs to use the same value in a different scope. 
			\item We want to look at \textbf{data that is stored on the heap} and explore how Rust knows when to clean up that data, and the \textbf{String} type is a great example
		\end{itemize}
	\end{frame}
	
	
	\begin{frame}[fragile]
		\frametitle{The String Type (2)}
		\begin{itemize}
			\item String literals(\mintinline{rust}|&str|) are hard-coded into our program (\textbf{fast and efficient}). String literals are convenient, but they aren’t suitable for every situation in which we may want to use text.
			\begin{itemize}
				\item 	One reason is that they’re \textbf{immutable}. 
				\item 	Another is that not every string value can be known when we write our code (for example, user input) 
			\end{itemize}
			\item 	For these situations, Rust has a second string type, \mintinline{rust}|String|.
			\begin{itemize}
				\item This type manages data allocated on the \textbf{heap} and as such is able to store an amount of text that is unknown to us at compile time.
				\item  You can create a \mintinline{rust}|String| from a string literal using the from function, like so: \mintinline{rust}|let s = String::from("hello");|.
			\end{itemize}
		\end{itemize}
	\end{frame}
	
	\begin{frame}[fragile]
		\frametitle{The String Type (3)}}
	\scriptsize
	\inputminted{rust}{./code/string.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Move}
	\inputminted{rust}{./code/move.rs}
	
	Bind the value 5 to x; then make a copy of the value in x and bind it to y.”  Because \textbf{integers are simple values with a known, fixed size}, and these two 5 values are pushed onto the \textbf{stack}
	
	\begin{block}{Primitive type on stack}
		\textbf{Primitive type}'s size known and fixed  so pushed onto the \textbf{stack}
	\end{block}
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{Move (2)}
	
	\begin{columns}
		\column{0.6\textwidth}
		\inputminted{rust}{./code/move-string.rs}
		\column{0.4\textwidth}
		\begin{figure}
			\centering
			\includegraphics[width=0.65\textwidth]{./img/trpl04-01.png}
			\caption{a String in memory}
			\label{fig:figureS1}
		\end{figure}
	\end{columns}
	
	The second line would make a copy of the value in s1 and bind it to s2. But this isn’t quite what happens.
	
	\textbf{A String is made up of three parts, shown on the left: a pointer to the memory that holds the contents of the string, a length, and a capacity. This group of data is stored on the stack. On the right is the memory on the heap that holds the contents.}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Move (3)}
	When we assign s1 to s2, the String data is copied, meaning we copy the pointer, the length, and the capacity that are on the stack. We do not copy the data on the heap that the pointer refers to. In other words, the data representation in memory looks like the following ( sounds like making a \textbf{shallow copy}):
	\begin{figure}
		\centering
		\includegraphics[width=0.3\textwidth]{./img/trpl04-02.png}
		\caption{Representation in memory of the variable s2 that has a copy of the pointer, length, and capacity of s1}
		\label{fig:figureS2}
	\end{figure}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Another possibility for what s2 = s1 might do if Rust copied the heap data as well}
	The representation does not look like the following Figure, which is what memory would look like if Rust instead copied the heap data as well. If Rust did this, the operation s2 = s1 could be very expensive in terms of runtime performance if the data on the heap were large (\textbf{deep copy}).
	\begin{figure}
		\centering
		\includegraphics[width=0.3\textwidth]{./img/trpl04-03.png}
		\label{fig:figureSAnotherPossibility}
	\end{figure}
\end{frame}

\begin{frame}[fragile]
	\frametitle{s1 was moved into s2}
	\begin{itemize}
		\item When a variable goes out of scope, \textbf{Rust automatically calls the drop function and cleans up the heap memor}y for that variable. 
		\item When s2 and s1 go out of scope, they will both try to free the same memory. This is known as a \textbf{double free error} and is one of the memory safety bugs.
		\item \textbf{Freeing memory twice} can lead to memory corruption, which can potentially lead to security vulnerabilities.
		\item To ensure memory safety, after the line let s2 = s1;, Rust considers s1 as no longer valid. Therefore, Rust doesn’t need to free anything when s1 goes out of scope.
	\end{itemize}
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{s1 was moved into s2 (2)}
	\inputminted{rust}{./code/move-string.rs}
\end{frame}
\begin{frame}[fragile]
	\frametitle{s1 was moved into s2 (3)}
	\inputminted{shell}{./code/move-string.shell}
\end{frame}

\begin{frame}[fragile]
	\frametitle{s1 was moved into s2 (4)}
	If you’ve heard the terms shallow copy and deep copy while working with other languages, the concept of copying the pointer, length, and capacity without copying the data probably sounds like making a shallow copy. But \textbf{because Rust also invalidates the first variable, instead of being called a shallow copy, it’s known as a move}. In this example, we would say that s1 was moved into s2. 
	\begin{figure}
		\centering
		\includegraphics[width=0.3\textwidth]{./img/trpl04-04.png}
		\label{fig:figureMove}
	\end{figure}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Move notes}
	
	\begin{block}{Memory safety bugs}
		That solves our problem! With only s2 valid, when it goes out of scope it alone will free the memory, and we’re done.
	\end{block}
	
	
	\begin{block}{Design choice}
		Rust will never automatically create “deep” copies of your data. Therefore, any automatic copying can be assumed to be inexpensive in terms of runtime performance.
	\end{block}
	
\end{frame}



\begin{frame}[fragile]
	\frametitle{Deeply copy with clone}
	If we do want to deeply copy the heap data of the String, not just the stack data, we can use a common method called clone.
	
	\begin{columns}
		\column{0.6\textwidth}
		\inputminted{rust}{./code/move-clone.rs}
		\column{0.4\textwidth}
		\begin{figure}
			\centering
			\includegraphics[width=0.8\textwidth]{./img/trpl04-03.png}
			\label{fig:figureSAnotherPossibility2}
		\end{figure}
	\end{columns}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Stack-Only Data: Copy and Clone}
	We don’t have a call to clone, but x is still valid and wasn’t moved into y.
	\inputminted{rust}{./code/move2.rs}
	
	The reason is that types such as integers that have \textbf{a known size at compile time} are stored entirely on the \textbf{stack}, so \textbf{copies of the actual values are quick to make}. That means there’s no reason we would want to prevent x from being valid after we create the variable y. In other words, there’s no difference between deep and shallow copying here, so calling clone wouldn’t do anything different from the usual shallow copying, and we can leave it out.
\end{frame}

\begin{frame}[fragile]
	\frametitle{Ownership and Functions}
	\inputminted[fontsize=\scriptsize]{rust}{./code/ownership-functions.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Return Values and Scope}
	\inputminted[fontsize=\scriptsize]{rust}{./code/ownership-return.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Returning ownership}
	\inputminted{rust}{./code/ownership-return2.rs}
	Rust has a feature for using a value without transferring ownership, called \textbf{\textit{references}}.
\end{frame}

\begin{frame}[fragile]
	\frametitle{References}
	A reference is\textbf{ like a pointer} in that it’s \textbf{an address we can follow to access the data} stored at that address; \textbf{that data is owned by some other variable}. Unlike a pointer,\textbf{ a reference is guaranteed to point to a valid value of a particular type for the life of that reference}.
	\begin{columns}
		\column{0.7\textwidth}
		\inputminted[fontsize=\scriptsize]{rust}{./code/references.rs}
		\column{0.3\textwidth}
		\small
		Note that we pass \&s1 into calculate\_length and, in its definition, we take \&String rather than String. These ampersands represent references, and they allow you to refer to some value without taking ownership of it
	\end{columns}
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{References (2)}
	\inputminted[fontsize=\scriptsize]{rust}{./code/references.rs}
	\begin{figure}
		\centering
		\includegraphics[width=0.6\textwidth]{./img/trpl04-05.png}
		\label{fig:figureRef}
	\end{figure}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Borrowing}
	\textbf{borrowing}: \textit{the action of creating a reference}.
	As in real life, if a person owns something, you can borrow it from them. When you’re done, you have to give it back. You don’t own it. So, what happens if we try to modify something we’re borrowing?
	\inputminted{rust}{./code/borrowing.rs}
	
	\small
	Just as variables are immutable by default, so are references. We’re not allowed to modify something we have a reference to.
\end{frame}

\begin{frame}[fragile]
	\frametitle{Borrowing (2)}
	\inputminted{shell}{./code/borrowing.shell}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Borrowing, Mutable References}
	We can fix the code to allow us to modify a borrowed value with just a few small tweaks that use, instead, a mutable reference (\mintinline{rust}|&mut|).
	\inputminted{rust}{./code/borrowing-mut-ref.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Mutable references restriction}
	\textbf{If you have a mutable reference to a value, you can have no other references to that value}. 
	\inputminted{rust}{./code/borrowing-mut-ref-err1.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Mutable references restriction (2)}
	\inputminted[fontsize=\scriptsize]{shell}{./code/borrowing-mut-ref-err1.shell}
	
	\scriptsize
	This error says that this code is invalid because we cannot borrow s as mutable more than once at a time. The first mutable borrow is in r1 and must last until it’s used in the println!, but between the creation of that mutable reference and its usage, we tried to create another mutable reference in r2 that borrows the same data as r1.
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{Why mutable references restriction exist in Rust?}
	It’s something that new Rustaceans struggle with because most languages let you mutate whenever you’d like. The benefit of having this restriction is that \textbf{Rust can prevent data races at compile time}. 
	
	A data race is similar to a race condition and happens when these three behaviors occur:
	
	\begin{itemize}
		\item Two or more pointers access the same data at the same time.
		\item 	At least one of the pointers is being used to write to the data.
		\item 	There’s no mechanism being used to synchronize access to the data.
	\end{itemize}
	Data races cause undefined behavior and can be difficult to diagnose and fix when you’re trying to track them down at runtime.
	
\end{frame}


\begin{frame}[fragile]
	\frametitle{Mutable references restriction example}
	As always, we can use curly brackets to create a new scope, allowing for multiple mutable references, just not simultaneous ones:
	\inputminted{rust}{./code/borrowing-simultaneous.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Mutable references restriction example (combining mutable and immutable references)}
	\inputminted{rust}{./code/borrowing-combining.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Mutable references restriction example (combining mutable and immutable references)}
	\inputminted{shell}{./code/borrowing-combining.shell}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Mutable references restriction example (combining mutable and immutable references, note to  reference’s scope)}
	\inputminted{rust}{./code/borrowing-combining-note.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Dangling References}
	In languages with pointers, it’s easy to erroneously create a dangling pointer—\textbf{a pointer that references a location in memory that may have been given to someone else}—by freeing some memory while preserving a pointer to that memory. In Rust, by contrast, \textbf{the compiler guarantees that references will never be dangling references}: if you have a reference to some data, the compiler will ensure that the data will not go out of scope before the reference to the data does.
	\inputminted[fontsize=\scriptsize]{rust}{./code/dangling.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Dangling References (2)}
	
	\inputminted{shell}{./code/dangling.shell}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Dangling References (3), solution}
	The solution here is to return the String directly:
	
	\inputminted{rust}{./code/dangling-sol.rs}
	
	This works without any problems. \textbf{Ownership is moved out, and nothing is deallocated.}
\end{frame}


\begin{frame}[fragile]
	\frametitle{The Slice Type}
	\textbf{Slices} let you \textbf{reference a contiguous sequence of elements in a collection} rather than the whole collection. A slice is \textbf{a kind of reference, so it does not have ownership}.
\end{frame}

\begin{frame}[fragile]
	\frametitle{Learn application of Slice Type by example}
	Here’s a small programming problem: write a function that takes a string of words separated by spaces and returns the first word it finds in that string.
	\scriptsize
	\inputminted[fontsize=\scriptsize]{rust}{./code/slice.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Learn application of Slice Type by example}
	\begin{itemize}
		\item This program compiles without any errors and would also do so if we used word after calling s.clear(). Because word isn’t connected to the state of s at all, word still contains the value 5. We could use that value 5 with the variable s to try to extract the first word out, but this would be a bug because the contents of s have changed since we saved 5 in word.
		\item Luckily, Rust has a solution to this problem: string slices.
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{String Slices}
	
	\begin{columns}
		\column{0.6\textwidth}
		\inputminted{rust}{./code/string-slice.rs}
		\column{0.4\textwidth}
		\begin{figure}
			\centering
			\includegraphics[width=0.8\textwidth]{./img/trpl04-06.png}
		\end{figure}
		
	\end{columns}
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{Rewrite first\_word to return a slice}
	\inputminted{rust}{./code/slice2.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{ Rewrite first\_word to return a slice (2)}
	\inputminted{shell}{./code/slice2.shell}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Rewrite first\_word to return a slice (3)}
	Recall from the borrowing rules that if we have an immutable reference to something, we cannot also take a mutable reference. Because clear needs to truncate the String, it needs to get a mutable reference. The println! after the call to clear uses the reference in word, so the immutable reference must still be active at that point. Rust disallows the mutable reference in clear and the immutable reference in word from existing at the same time, and compilation fails. Not only has Rust made our API easier to use, but it has also eliminated an entire class of errors at compile time!
\end{frame}

\begin{frame}[fragile]
	\frametitle{Improve first\_word function}
	\mintinline{rust}|fn first_word(s: &String) -> &str {/*...*/}| 
	
	A more experienced Rustacean would write the signature as in below instead because it allows us to use the same function on both \mintinline{rust}|&String|  values and  \mintinline{rust}|&str|  values.
	
	\mintinline{rust}|fn first_word(s: &str) -> &str {/*...*/}| 
\end{frame}


\section{Using Structs to Structure Related Data}

\begin{frame}[fragile]
	\frametitle{Defining and Instantiating Structs}
	\begin{itemize}
		\item A\textbf{ struct, or structure,} is a custom data type that lets you package together and name multiple related values that make up a meaningful group. If you’re familiar with an object-oriented language, a struct is like an\textit{ object’s data attributes}.
		\item 	\textbf{Structs are similar to tuples}, in that both hold multiple related values. Like tuples, the pieces of a struct can be different types. Unlike with tuples, in a struct you’ll name each piece of data so it’s clear what the values mean. Adding these names means that structs are more flexible than tuples: you don’t have to rely on the order of the data to specify or access the values of an instance.
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Defining and Instantiating Structs (2)}
	\inputminted{rust}{./code/struct.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Using the Field Init Shorthand}
	\inputminted{rust}{./code/field-shorthand.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Creating Instances From Other Instances With Struct Update Syntax}
	\inputminted{rust}{./code/struct-build.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Creating Instances From Other Instances With Struct Update Syntax (2)}
	The ..user1 \textbf{must come last to specify that any remaining fields should get their values from the corresponding fields} in user1.
	
	\begin{block}{Note that the struct update syntax uses = like an assignment}
		This is because it moves the data. In this example, we can no longer use user1 after creating user2 because the String in the username field of user1 was moved into user2. If we had given user2 new String values for both email and username, and thus only used the active and sign\_in\_count values from user1, then user1 would still be valid after creating user2. The types of active and sign\_in\_count are types that implement the Copy trait.
	\end{block}
	
\end{frame}


\begin{frame}[fragile]
	\frametitle{Creating Instances From Other Instances With Struct Update Syntax (3)}
	\inputminted{rust}{./code/struct-err.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Creating Instances From Other Instances With Struct Update Syntax (4)}
	\inputminted{shell}{./code/struct-err2.shell}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Ownership of Struct Data}
	\begin{itemize}
		\item In the User struct definition,\textbf{ we used the owned String type rather than the \mintinline{rust}|&str| string slice type.} This is a deliberate choice because we want each instance of this struct to own all of its data and for that data to be valid for as long as the entire struct is valid.
		\item 	\textbf{It’s also possible for structs to store references to data owned by something else, but to do so requires the use of lifetimes}, a Rust feature that we’ll discuss later. Lifetimes ensure that the data referenced by a struct is valid for as long as the struct is.
	\end{itemize}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Using Tuple Structs without Named Fields to Create Different Types}
	Rust also supports structs that look similar to tuples, called tuple structs. Tuple structs have the added meaning the struct name provides but don’t have names associated with their fields; rather, they just have the types of the fields. Tuple structs are useful when you want to give the whole tuple a name and make the tuple a different type from other tuples, and when naming each field as in a regular struct would be verbose or redundant.
	\inputminted{rust}{./code/tuple-struct.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Unit-Like Structs Without Any Fields}
	You can also define structs that don’t have any fields! These are called \textbf{unit-like structs} because they behave similarly to ().
	\inputminted{rust}{./code/unit-like-struct.rs}
	
	\begin{block}{Unit type}
		The tuple without any values has a special name, unit. This value and its corresponding type are both written () and represent an empty value or an empty return type. Expressions implicitly return the unit value if they don’t return any other value.
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Unit-Like Structs Without Any Fields (2)}
	Unit-like structs can be useful when you need to implement a trait on some type but don’t have any data that you want to store in the type itself. 
	Example, see: The global memory allocator, \href{https://doc.rust-lang.org/src/alloc/alloc.rs.html#59}{\colorbox{lightgray}{Global}}, is a unit struct.
\end{frame}

\begin{frame}[fragile]
	\frametitle{Method Syntax}
	\textbf{Methods} are similar to \textbf{functions}: we declare them with the \mintinline{rust}|fn| keyword and a name, they can have parameters and a return value, and they contain some code that’s run when the method is called from somewhere else. Unlike functions, methods are defined within the context of a struct (or an enum or a trait object, which we cover later), and their \textbf{first parameter is always self}, which represents the instance of the struct the method is being called on.
\end{frame}

\begin{frame}[fragile]
	\frametitle{Method Syntax(2)}
	\inputminted{rust}{./code/method.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Associated Functions}
	\begin{itemize}
		\item \textbf{All functions defined within an \mintinline{rust}|impl|  block} are called associated functions because they’re associated with the type named after the  \mintinline{rust}|impl| . We can define associated functions that don’t have self as their first parameter (and\underline{ thus are not methods}) because they don’t need an instance of the type to work with. We’ve already used one function like this: the String::from function that’s defined on the String type.
		\item 	Associated functions that aren’t methods are often used for constructors that will return \textbf{a new instance of the struct}(factory method). These are often called \textbf{new}, but new isn’t a special name and isn’t built into the language.
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Associated Functions}
	\inputminted{rust}{./code/factory-method.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Multiple \mintinline{rust}|impl| Blocks}
	\inputminted{rust}{./code/multi-impl.rs}
\end{frame}

\section{Enums and Pattern Matching}
\begin{frame}[fragile]
	\frametitle{Defining an Enum}
	Enums allow you to define a type by enumerating its possible variants.
	\begin{block}{Struct vs Enum}
		Where structs give you a way of grouping together related fields and data, like a Rectangle with its width and height, enums give you a way of saying a value is one of a possible set of values. 
	\end{block}
	\inputminted{rust}{./code/enum.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Defining an Enum (2)}
	There’s another advantage to using an enum rather than a struct:\textbf{ each variant can have different types and amounts of associated data}. 
	\inputminted{rust}{./code/enum2.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Defining an Enum (3)}
	
	\inputminted{rust}{./code/enum3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{The Option Enum and Its Advantages Over Null Values}
	The Option type encodes the very common scenario in which a value could be something or it could be nothing.
	\inputminted{rust}{./code/enum4.rs}
	
	see: “Null References: The Billion Dollar Mistake”
\end{frame}

\begin{frame}[fragile]
	\frametitle{Advantage of Option Over Null}
	\begin{itemize}
		\item 	When we have a Some value, we know that a value is present and the value is held within the Some. When we have a None value, in some sense, it means the same thing as null: we don’t have a valid value. So why is having \mintinline{rust}|Option<T>| any better than having null?
		\begin{itemize}
			\item 	In short, because \mintinline{rust}|Option<T>| and T (where T can be any type) are different types, the compiler won’t let us use an \mintinline{rust}|Option<T>| value as if it were definitely a valid value. For example, this code won’t compile because it’s trying to add an \mintinline{rust}|i8| to an \mintinline{rust}|Option<i8>|:
		\end{itemize}
	\end{itemize}
	
	\inputminted{rust}{./code/enum5.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{The match Control Flow Construct}
	Rust has an extremely powerful control flow construct called \mintinline{rust}|match| that allows you to compare a value against a series of patterns and then execute code based on which pattern matches.
	\inputminted{rust}{./code/match.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Patterns that Bind to Values}
	\begin{columns}
		\column{0.8\textwidth}
		\inputminted[fontsize=\scriptsize]{rust}{./code/match2.rs}
		\column{0.2\textwidth}
		Another useful feature of match arms is that they can bind to the parts of the values that match the pattern. This is how we can extract values out of enum variants.
	\end{columns}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Matching with \mintinline{rust}|Option<T>| }
	\inputminted{rust}{./code/match3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Matches Are Exhaustive }
	Matches in Rust are exhaustive: we must exhaust every last possibility in order for the code to be valid. Especially in the case of \mintinline{rust}|Option<T>|, when Rust prevents us from forgetting to explicitly handle the None case, it protects us from assuming that we have a value when we might have null, thus making the billion-dollar mistake impossible.
	\inputminted{rust}{./code/match4.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Catch-all Patterns and the \_ Placeholder}
	\inputminted{rust}{./code/match5.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Concise Control Flow with if let}
	The if let syntax lets you combine if and let into a less verbose way to handle values that match one pattern while ignoring the rest.
	\inputminted{rust}{./code/match6.rs}
\end{frame}

\section{Managing Projects with Packages, Crates, and Modules}
\begin{frame}[fragile]
	\frametitle{Packages and Crates}
	\begin{itemize}
		\item As a project grows, you should organize code by splitting it into multiple \textbf{modules} and then multiple files. 
		\item 	A \textbf{package} can contain multiple binary crates and optionally one library crate. 
		\item 	As a package grows, you can extract parts into separate crates that become external dependencies.
		\item 	A \textbf{crate} is the smallest amount of code that the Rust compiler considers at a time. A crate can come in one of two forms: 
		\begin{itemize}
			\item \textbf{Binary crates }are programs you can compile to an executable, such as a command-line program or a server. Each must have a function called \mintinline{rust}|main| that defines what happens when the executable runs. 
			\item 	\textbf{Library crates} don’t have a main function, and they don’t compile to an executable. Instead, they define functionality intended to be shared with multiple projects.
		\end{itemize}
		
		\item 	For very large projects comprising a set of interrelated packages that evolve together, Cargo provides \textbf{workspaces}, which we’ll cover later.
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Module system}
	\begin{figure}
		\centering
		\includegraphics[width=0.65\textwidth]{./img/package.jpeg}
	\end{figure}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Package}
	\begin{itemize}
		\item A package is a bundle of one or more crates that provides a set of functionality. A package contains a Cargo.toml file that describes how to build those crates.
		\item 	After we run \mintinline{shell}|cargo new|, we use \mintinline{shell}|ls| to see what Cargo creates. In the project directory, there’s a \mintinline{shell}|Cargo.toml| file, giving us a package. There’s also a src directory that contains \mintinline{shell}|main.rs|. Cargo knows that if the package directory contains \mintinline{shell}|src/lib.rs|, the package contains a library crate with the same name as the package, and src/lib.rs is its crate root.
		\item If a package contains \mintinline{shell}|src/main.rs| and \mintinline{shell}|src/lib.rs|, it has two crates: a binary and a library, both with the same name as the package. 
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Declaring modules}
	In the crate root file, you can \textbf{declare new modules}; say, you declare a “garden” module with  \mintinline{rust}|mod garden;|. The compiler will look for the module’s code in these places:
	\begin{itemize}
		\item 	\textbf{Inline}, within curly brackets that replace the semicolon following \mintinline{rust}|mod garden|
		\item 	\textbf{In the file} src/garden.rs
		\item 	\textbf{In the file} src/garden/mod.rs
	\end{itemize}
	
	\textbf{Declaring submodules}: In any file other than the crate root, you can declare submodules. For example, you might declare \mintinline{rust}|mod vegetables;| in src/garden.rs. The compiler will look for the submodule’s code within the directory named for the parent module in these places:
	\begin{itemize}
		\item 	\textbf{Inline}, directly following mod vegetables, within curly brackets instead of the semicolon
		\item 	\textbf{In the file} src/garden/vegetables.rs
		\item 	\textbf{In the file} src/garden/vegetables/mod.rs
	\end{itemize}
	
\end{frame}


\begin{frame}[fragile]
	\frametitle{Control the privacy with modules}
	\begin{itemize}
		\item Modules let us organize code within a crate for readability and easy reuse. 
		\item 	Modules also\textbf{ allow us to control the privacy of items}, because \textbf{code within a module is private by default}. Private items are internal implementation details not available for outside use.
	\end{itemize}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Paths to code in modules}
	\begin{columns}
		\column{0.3\textwidth}
		Once a module is part of your crate, you can refer to code in that module from anywhere else in that same crate, as long as the privacy rules allow, using the path to the code. For example, an Asparagus type in the garden vegetables module would be found at \mintinline{rust}|crate::garden::vegetables::Asparagus|.
		\column{0.6\textwidth}
		\begin{figure}
			\centering
			\includegraphics[width=0.9\textwidth]{./img/trpl04-07.png}
		\end{figure}
	\end{columns}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Paths in the Module}
	A path can take two forms:
	
	\begin{itemize}
		\item 	An \textbf{absolute} path is the full path starting from a crate root; for code from an external crate, \textbf{the absolute path begins with the crate name}, and for code from the current crate, it starts with the literal crate.
		\item 	A \textbf{relative} path starts from the current module and \textbf{uses self, super, or an identifier in the current module}.
	\end{itemize}
	Both absolute and relative paths are followed by one or more identifiers separated by double colons (::).
\end{frame}


\begin{frame}[fragile]
	\frametitle{Paths in the Module (2)}
	
	\inputminted{rust}{./code/module.rs}
	
	Both \mintinline{rust}|front_of_house| module and \mintinline{rust}|add_to_waitlist|  method are public. The \mintinline{rust}|pub| keyword lets us use these paths in \mintinline{rust}|add_to_waitlist| with respect to the privacy rules.
\end{frame}

\begin{frame}[fragile]
	\frametitle{Siblings are friend}
	While \mintinline{rust}|front_of_house| isn’t public, because the \mintinline{rust}|eat_at_restaurant| function is defined in the same module as \mintinline{rust}|front_of_house| (that is, \mintinline{rust}|eat_at_restaurant| and \mintinline{rust}|front_of_house| are siblings), we can refer to \mintinline{rust}|front_of_house|  from \mintinline{rust}|eat_at_restaurant|. 
\end{frame}


\begin{frame}[fragile]
	\frametitle{Starting Relative Paths with \mintinline{rust}|super| }
	\inputminted{rust}{./code/module2.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Making Structs Public}
	\inputminted[fontsize=\fontsize{8pt}{8pt}]{rust}{./code/module3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Making Enums Public}
	\inputminted{rust}{./code/module4.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Bringing Paths into Scope with the \mintinline{rust}|use|  Keyword}
	\begin{itemize}
		\item Having to write out the paths to call functions can feel inconvenient and repetitive. 
		\item 	Fortunately, there’s a way to simplify this process: we can create a shortcut to a path with the use keyword once, and then \mintinline{rust}|use| the shorter name everywhere else in the \textbf{scope}.
	\end{itemize}
	\inputminted{rust}{./code/module5.rs}
	
	Note that  \mintinline{rust}|use| only creates the shortcut for the particular scope in which the use occurs.
\end{frame}


\begin{frame}[fragile]
	\frametitle{Bringing Paths into Scope with the \mintinline{rust}|use|  Keyword (2)}
	\inputminted{rust}{./code/module6.rs}
	To fix this problem, move the \mintinline{rust}|use| within the \mintinline{rust}|customer| module too, or reference the shortcut in the parent module with \mintinline{rust}|super::hosting|  within the child \mintinline{rust}|customer| module.
\end{frame}



\begin{frame}[fragile]
	\frametitle{Creating Idiomatic \mintinline{rust}|use| Paths}
	\inputminted[fontsize=\scriptsize]{rust}{./code/module8.rs}
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/module7.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Creating Idiomatic \mintinline{rust}|use| Paths (2)}
	\begin{itemize}
		\item Bringing the function’s parent module into scope with \mintinline{rust}|use| means we have to specify the parent module when calling the function. \textbf{Specifying the parent module when calling the function makes it clear that the function isn’t locally defined while still minimizing repetition of the full path}. 
		\item On the other hand, when bringing in structs, enums, and other items with use, it’s idiomatic to specify the full path. There’s no strong reason behind this idiom: it’s just the convention that has emerged, and folks have gotten used to reading and writing Rust code this way.
		\inputminted[fontsize=\scriptsize]{rust}{./code/module9.rs}
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Creating Idiomatic \mintinline{rust}|use| Paths (3)}
	\inputminted[fontsize=\scriptsize]{rust}{./code/module10.rs}
	
	\begin{block}{Idiomatic way}
		\begin{itemize}
			\item 	\textbf{Function}: bringing the \textbf{function’s parent} module into scope.
			\item 	\textbf{Structs, enums, and other items}: it’s idiomatic to specify the \textbf{full path}.
			\begin{itemize}
				\item The exception to this idiom is if we’re bringing two items with the same name into scope with \mintinline{rust}|use|  statements, because Rust doesn’t allow that.
			\end{itemize}
		\end{itemize}
	\end{block}
	
\end{frame}



\begin{frame}[fragile]
	\frametitle{Providing New Names with the as Keyword}
	\inputminted[fontsize=\scriptsize]{rust}{./code/module11.rs}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Re-exporting Names with \mintinline{rust}|pub use|}
	When we bring a name into scope with the use keyword, the name available in the new scope is private. To enable the code that calls our code to refer to that name as if it had been defined in that code’s scope, we can combine  \mintinline{rust}|pub| and  \mintinline{rust}|use|.
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/module12.rs}
	
	\scriptsize
	It makes our library well organized for programmers working on the library and programmers calling the library. 
\end{frame}



\begin{frame}[fragile]
	\frametitle{Using External Packages}
	Members of the Rust community have made many packages available at \url{crates.io}, and pulling any of them into your package involves these same steps: listing them in your package’s \mintinline{rust}|Cargo.toml| file and using use to bring items from their crates into scope. Example:
	
	1) Add the following line to \mintinline{rust}|Cargo.toml| file.
	
	\mintinline{toml}|rand = "0.8.5"|
	
	2) bring items from the crates into scope (with \mintinline{rust}|use|) and used it.
	\inputminted{rust}{./code/module13.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Using Nested Paths to Clean Up Large \mintinline{rust}|use| Lists}
	\inputminted{rust}{./code/module14.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Separating Modules into Different Files}
	\begin{itemize}
		\item For a module named  \mintinline{rust}|front_of_house| declared in the crate root, the compiler will look for the module’s code in:
		\begin{itemize}
			\item \mintinline{rust}|src/front_of_house.rs| (what we covered)
			\item 	\mintinline{rust}|src/front_of_house/mod.rs| (older style, still supported path)
		\end{itemize}
		\item 	For a module named hosting that is a submodule of \mintinline{rust}|front_of_house| , the compiler will look for the module’s code in:
		\begin{itemize}
			\item \mintinline{rust}|src/front_of_house/hosting.rs| (what we covered)
			\item 	\mintinline{rust}|src/front_of_house/hosting/mod.rs| (older style, still supported path)
		\end{itemize}
		\item 	If you use both styles for the same module, you’ll get a compiler error. Using a mix of both styles for different modules in the same project is allowed, but might be confusing for people navigating your project.
		\item The main downside to the style that uses files named mod.rs is that your project can end up with many files named mod.rs, which is confusing.
	\end{itemize}
	
\end{frame}

\section{Common Collections}
\begin{frame}[fragile]
	\frametitle{Collections}
	\begin{itemize}
		\item \textbf{Rust’s standard library} includes a number of very useful \textbf{data structures} called \textbf{collections}. 
		\item 	Most other data types represent one specific value, but collections can contain multiple values. 
		\item 	Unlike the built-in array and tuple types, the data these collections point to is stored on the \textbf{heap}, which means the amount of data does not need to be known at compile time and can grow or shrink as the program runs.
		\item 	Each kind of collection has different capabilities and costs, and choosing an appropriate one for your current situation is a skill you’ll develop over time. 
		\item Rust’s collections can be grouped into four major categories:
		\begin{itemize}
			\item 	\textbf{Sequences}: Vec, VecDeque(double-ended queue), LinkedList
			\item 	\textbf{Maps}: HashMap, BTreeMap
			\item 	\textbf{Sets}: HashSet, BTreeSet
			\item 	\textbf{Misc}: BinaryHeap
		\end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Creating a New Vector}
	\inputminted{rust}{./code/vector.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Reading Elements of Vectors}
	There are two ways to reference a value stored in a vector: via indexing or using the get method. 
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/vector2.rs}
	
	The reason Rust provides these two ways to reference an element is so you can choose how the program behaves when you try to use an index value outside the range of existing elements.
\end{frame}


\begin{frame}[fragile]
	\frametitle{Iterating over the Values in a Vector}
	\inputminted{rust}{./code/vector3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Using an Enum to Store Multiple Types}
	\inputminted{rust}{./code/vector4.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Using an Enum to Store Multiple Types}
	\inputminted{rust}{./code/vector4.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{What Is a \mintinline{rust}|String|?}
	
	\begin{itemize}
		\item 	Many of the same operations available with \mintinline{rust}|Vec<T>|  are available with \mintinline{rust}|String| as well, because String is actually implemented as a wrapper around \textbf{a vector of bytes} with some extra guarantees, restrictions, and capabilities.
		\item 	Rust has only one \textbf{string type}\textit{ in the core language}, which is the \textbf{string slice} \mintinline{rust}|str| that is usually seen in its borrowed form \mintinline{rust}|&str|. 
		\item 	The \textbf{String type}, which is provided by\textbf{ Rust’s standard library} rather than coded into the core language, is \textit{a growable, mutable, owned, UTF-8 encoded string type}. When Rustaceans refer to “strings” in Rust, they might be referring to either the String or the string slice \mintinline{rust}|&str| types, not just one of those types. 
	\end{itemize}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Creating a New String}
	\inputminted{rust}{./code/string_vec.rs}
	
	Because strings are used for so many things, we can use many different generic APIs for strings, providing us with a lot of options. Some of them can seem redundant, but they all have their place! In this case, \mintinline{rust}|String::from| and \mintinline{rust}|to_string| do the same thing, so which you choose is a matter of style and readability.
\end{frame}


\begin{frame}[fragile]
	\frametitle{Updating a String}
	\inputminted{rust}{./code/string_vec2.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Hash Maps}
	\inputminted{rust}{./code/map.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Hash Maps and Ownership}
	For types that implement the Copy trait, like i32, the values are copied into the hash map. For owned values like String, the values will be moved and the hash map will be the owner of those values.
	
	\inputminted{rust}{./code/map2.rs}
\end{frame}

\section{Error Handling}

\begin{frame}[fragile]
	\frametitle{Rust errors categories}
	Rust groups errors into two major categories: \textbf{recoverable} and \textbf{unrecoverable} errors. 
	\begin{itemize}
		\item For a \textbf{recoverable} error, such as a file not found error, we most likely just want to report the problem to the user and retry the operation. 
		\item 	\textbf{Unrecoverable} errors are always \textbf{symptoms of bugs}, like trying to access a location beyond the end of an array, and so we want to immediately \textbf{stop the program}.
		\item  Rust doesn’t have exceptions. Instead, it has the type \mintinline{rust}|Result<T, E>| for recoverable errors and the  \mintinline{rust}|panic!| macro that stops execution when the program encounters an unrecoverable error.
	\end{itemize}
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{Unrecoverable Errors with panic!}
	\inputminted{rust}{./code/panic.rs}
	
	\begin{block}{Unwinding the Stack }
		By default, when a panic occurs, the program starts unwinding, which means Rust walks back up the stack and cleans up the data from each function it encounters. However, this walking back and cleanup is a lot of work. Rust, therefore, allows you to choose the alternative of immediately aborting, which ends the program without cleaning up.
	\end{block}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Recoverable Errors with Result}
	Most errors aren’t serious enough to require the program to stop entirely. Sometimes, when a function fails, it’s for a reason that you can easily interpret and respond to (For example, open a file that doesn’t exist).
	
	\scriptsize
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/result.rs}
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/result2.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Matching on Different Errors}
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/result3.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Alternatives to Using match with \mintinline{rust}|Result<T, E>| }
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/result4.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Shortcuts for Panic on Error: unwrap and expect }
	\scriptsize
	The \mintinline{rust}|Result<T, E>| type has many helper methods defined on it to do various, more specific tasks. If the Result value is the Ok variant, unwrap will return the value inside the Ok. If the Result is the Err variant, unwrap will call the panic! macro for us.
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/result5.rs}
	
	We use  \mintinline{rust}|expect| in the same way as unwrap: to return the file handle or call the panic! macro.
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/result6.rs}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Propagating Errors with  \mintinline{rust}|?| Operator}
	\inputminted{rust}{./code/result8.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{A Shortcut for Propagating Errors: the \mintinline{rust}|?| Operator}
	\inputminted{rust}{./code/result7.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{A Shortcut for Propagating Errors: the \mintinline{rust}|?| Operator}
	\inputminted[fontsize=\scriptsize]{rust}{./code/result9.rs}
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/result10.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Where The \mintinline{rust}|?| Operator Can Be Used}
	\begin{itemize}
		\item 	The \mintinline{rust}|?| operator can only be used in functions whose return type is compatible with the value the \mintinline{rust}|?| is used on.
		\item 	we’re only allowed to use the ? operator in a function that returns \mintinline{rust}|Result|, \mintinline{rust}|Option|, or another type that implements \mintinline{rust}|FromResidual|.
	\end{itemize}
	
	\inputminted{rust}{./code/result11.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Where The \mintinline{rust}|?| Operator Can Be Used (2)}
	\inputminted{rust}{./code/result12.rs}
	
	The \mintinline{rust}| Box<dyn Error>| type is a trait object, which we’ll talk about later. For now, you can read \mintinline{rust}| Box<dyn Error>|  to mean “any kind of error.” 
	
\end{frame}

\section{Generic Types, Traits, and Lifetimes}

\begin{frame}[fragile]
	\frametitle{Generic Data Types}
	We use generics to create definitions for items like function signatures or structs, which we can then use with many different concrete data types.
	
	\begin{columns}
		\column{0.5\textwidth}
		\inputminted{rust}{./code/generic1.rs}
		\column{0.5\textwidth}
		\inputminted{rust}{./code/generic2.rs}
	\end{columns}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Generic Data Types (3)}
	\inputminted[fontsize=\scriptsize]{rust}{./code/generic3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Generic Data Types In Struct Definitions}
	\inputminted{rust}{./code/generic4.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Generic Data Types In Enum Definitions}
	\inputminted{rust}{./code/generic5.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Generic Data Types In Method Definitions}
	\inputminted[fontsize=\scriptsize]{rust}{./code/generic6.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Generic Data Types In Method Definitions(2)}
	\inputminted[fontsize=\scriptsize]{rust}{./code/generic7.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Monomorphization}
	Monomorphization is the process of turning generic code into specific code by filling in the concrete types that are used when \textbf{compiled}. In this process, the compiler does the opposite of the steps we used to create the generic function: the compiler looks at all the places where generic code is called and generates code for the concrete types the generic code is called with.
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{Monomorphization}
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/generic8.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Traits: Defining Shared Behavior}
	\begin{itemize}
		\item A trait defines functionality a particular type has and can share with other types. We can use traits \textbf{to define shared behavior in an abstract way}. We can use trait bounds to specify that a generic type can be any type that has certain behavior.
		\item 	Note: Traits are similar to a feature often called \textbf{interfaces in other languages}, although with some differences.
		\item 	Trait definitions are a way to group method signatures together to define a set of behaviors necessary to accomplish some purpose.
	\end{itemize}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Traits: Defining Shared Behavior (2)}
	\inputminted[fontsize=\scriptsize]{rust}{./code/Trait1.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Traits: Default Implementations}
	\inputminted[fontsize=\scriptsize]{rust}{./code/Trait2.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Traits as Parameters}
	\inputminted{rust}{./code/Trait3.rs}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Clearer Trait Bounds with where Clauses}
	A functions with multiple generic type parameters can contain lots of trait bound information between the function’s name and its parameter list, making the function signature hard to read. For this reason, Rust has alternate syntax for specifying trait bounds inside a where clause after the function signature. So instead of writing this:
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/trait4.rs}
	
	we can use a where clause, like this:
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/trait5.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Validating References with Lifetimes}
	\begin{itemize}
		\item lifetimes \textbf{ensure that references are valid as long as we need them to be}.
		\item 	Lifetimes are another \textbf{kind of generic} that we’ve already been using.
		\item 	Most of the time, lifetimes are implicit and inferred, just like most of the time, types are inferred. We only must annotate types when multiple types are possible.
		\item 	Annotating lifetimes is not even a concept most other programming languages have, so this is going to feel \textbf{unfamiliar}.
		\item The Rust compiler has a\textbf{ borrow checker} that compares scopes to determine whether all borrows are valid.
		\begin{itemize}
			\item borrowing: the action of creating a reference.
		\end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Preventing Dangling References with Lifetimes}
	Annotations of the lifetimes of r and x, named 'a and 'b, respectively
	
	\inputminted{rust}{./code/dangling-ref.rs}
	
	The variable x doesn’t “live long enough.” The reason is that x will be out of scope when the inner scope ends on line 7. But r is still valid for the outer scope; because its scope is larger, we say that it “lives longer.” 
\end{frame}

\begin{frame}[fragile]
	\frametitle{Preventing Dangling References with Lifetimes(2)}
	\inputminted{shell}{./code/dangling-ref.shell}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Generic Lifetimes in Functions}
	We’ll write a function that returns the longer of two string slices. This function will take two string slices and return a single string slice.
	
	\inputminted{rust}{./code/lifetime.rs}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Generic Lifetimes in Functions (2)}
	Rust can’t tell whether the reference being returned refers to x or y. Actually, we don’t know either, because the if block in the body of this function returns a reference to x and the else block returns a reference to y!
	
	\inputminted{rust}{./code/lifetime2.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Generic Lifetimes in Functions (3)}
	\inputminted{shell}{./code/lifetime2.shell}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Lifetime Annotation Syntax}
	\begin{itemize}
		\item 	Lifetime annotations \textbf{don’t change how long any of the references live}. Rather, they \textbf{describe the relationships of the lifetimes of multiple references to each other }without affecting the lifetimes.
		\item 	Lifetime annotations have a slightly \textbf{unusual syntax}: the names of lifetime parameters must start with an apostrophe (') and are usually all lowercase and very short, like generic types. Most people use the name \mintinline{rust}|'a| for the first lifetime annotation. We place lifetime parameter annotations after the \mintinline{rust}|&| of a reference, using a space to separate the annotation from the reference’s type.
		
		\inputminted{rust}{./code/lifetime3.rs}
	\end{itemize}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Lifetime Annotations in Function Signatures}
	\inputminted{rust}{./code/lifetime4.rs}
	
	The generic lifetime \mintinline{rust}|'a| will get the concrete \textbf{lifetime that is equal to the smaller of the lifetimes }of x and y. In practice, it means that the lifetime of the reference returned by the longest function is the same as the smaller of the lifetimes of the values referred to by the function arguments. These relationships are what we want Rust to use when analyzing this code.
\end{frame}


\begin{frame}[fragile]
	\frametitle{Lifetime Annotations in Function Signatures (2)}
	\inputminted{rust}{./code/lifetime5.rs}
	
	The error shows that for result to be valid for the \mintinline{rust}|println!| statement, string2 would need to be valid until the end of the outer scope. Rust knows this because we annotated the lifetimes of the function parameters and return values using the same lifetime parameter \mintinline{rust}|'a|.
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{Lifetime Annotations in Function Signatures (3)}
	\inputminted{shell}{./code/lifetime5.shell}
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{Lifetime Annotations in Struct Definitions}
	\inputminted{rust}{./code/lifetime6.rs}
	
	We can define structs to hold references, but in that case we would need to add a lifetime annotation on every reference in the struct’s definition.
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{Lifetime Elision}
	\begin{itemize}
		\item In early versions (pre-1.0) of Rust, every reference needed an explicit lifetime. After writing a lot of Rust code, the Rust team found that Rust programmers were entering the same lifetime annotations over and over in particular situations. These situations were predictable and followed a few deterministic patterns. After writing a lot of Rust code, the Rust team found that Rust programmers were entering \textbf{the same lifetime annotations over and over in particular situations. These situations were predictable and followed a few deterministic patterns}. 
		\item  \textbf{The patterns programmed into Rust’s analysis of references are called thelifetime elision} rules. These aren’t rules for programmers to follow; they’re a set of particular cases that the compiler will consider, and if your code fits these cases, you don’t need to write the lifetimes explicitly.
	\end{itemize}
	
\end{frame}


\begin{frame}[fragile]
	\frametitle{Lifetime Elision (2)}
	\begin{itemize}
		\item The first rule is that the compiler assigns a lifetime parameter to each parameter that’s a reference. In other words, a function with one parameter gets one lifetime parameter: \mintinline{rust}|fn foo<'a>(x: &'a i32);|  a function with two parameters gets two separate lifetime parameters: \mintinline{rust}|fn foo<'a, 'b>(x: &'a i32, y: &'b i32);| and so on.
		\item 	The second rule is that, if there is exactly one input lifetime parameter, that lifetime is assigned to all output lifetime parameters: \mintinline{rust}|fn foo<'a>(x: &'a i32) -> &'a i32|.
		\item 	The third rule is that, if there are multiple input lifetime parameters, but one of them is \mintinline{rust}|&self| or \mintinline{rust}|&mut self| because this is a method, the lifetime of \mintinline{rust}|self| is assigned to all output lifetime parameters. This third rule makes methods much nicer to read and write because fewer symbols are necessary.
	\end{itemize}
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{Lifetime Elision (2)}
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/lifetime7.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Lifetime Annotations in Method Definitions}
	When we implement methods on a struct with lifetimes, we use the same syntax as that of generic type parameters shown: 
	
	\inputminted{rust}{./code/lifetime8.rs}
	
	The lifetime parameter declaration after impl and its use after the type name are required, but we’re not required to annotate the lifetime of the reference to self because of the first elision rule.
\end{frame}

\begin{frame}[fragile]
	\frametitle{The Static Lifetime}
	One special lifetime we need to discuss is \mintinline{rust}|'static|, which denotes that the affected reference can live for the entire duration of the program. All string literals have the \mintinline{rust}|'static| lifetime, which we can annotate as follows:
	
	\inputminted{rust}{./code/lifetime9.rs}
	
	The text of this string is stored directly in the program’s binary, which is always available. Therefore, the lifetime of all string literals is 'static.
\end{frame}


\begin{frame}[fragile]
	\frametitle{Generic Type Parameters, Trait Bounds, and Lifetimes Together}
	
	\inputminted{rust}{./code/lifetime10.rs}
\end{frame}

\section{Writing Automated Tests}
\begin{frame}[fragile]
	\frametitle{The Anatomy of a Test Function}
	
	\inputminted{rust}{./code/test1.rs}
	
	\inputminted[fontsize=\scriptsize]{shell}{./code/test1.shell}
\end{frame}

\begin{frame}[fragile]
	\frametitle{ Adding a second test that will fail because we call the \mintinline{rust}|panic!| macro}
	
	\inputminted{rust}{./code/test2.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Checking Results with the  \mintinline{rust}|assert!| Macro}
	The \mintinline{rust}|assert!| macro, provided by the standard library, is useful when you want to ensure that some condition in a test evaluates to true. 
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/test3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Checking Results with the \mintinline{rust}|assert_eq!| and \mintinline{rust}|assert_ne!| Macro}
	
	\inputminted{rust}{./code/test4.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Adding Custom Failure Messages}
	You can also add a custom message to be printed with the failure message as optional arguments to the \mintinline{rust}|assert!|, \mintinline{rust}|assert_eq!|, and \mintinline{rust}|assert_ne!| macros. Any arguments specified after the required arguments are passed along to the \mintinline{rust}|format!| macro
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/test5.rs}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Checking for Panics with \mintinline{rust}|should_panic|}
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/test6.rs}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Using \mintinline{rust}|Result<T, E>| in Tests}
	
	\inputminted{rust}{./code/test7.rs}
	
	Writing tests so they return a \mintinline{rust}|Result<T, E>| enables you to use the question mark operator in the body of tests, which can be a convenient way to write tests that should fail if any operation within them returns an Err variant.
	
\end{frame}


\begin{frame}[fragile]
	\frametitle{Controlling How Tests Are Run}
	\begin{itemize}
		\item \mintinline{shell}|cargo test| compiles your code in test mode and runs the resulting test binary. The default behavior of the binary produced by cargo test is to \textbf{run all the tests in parallel} and capture output generated during test runs,\textbf{ preventing the output from being displayed} and making it easier to read the output related to the test results. You can, however, specify command line options to change this default behavior.
		\item If you don’t want to run the tests in parallel or if you want more fine-grained control over the number of threads used, you can send the \mintinline{shell}|--test-threads|  flag and the number of threads you want to use to the test binary (ex: \mintinline{shell}|cargo test -- --test-threads=1| ).
		\item If we call \mintinline{rust}|println!|  in a test, we won’t see the \mintinline{rust}|println!| output in the terminal. If we want to see printed values for passing tests, we can tell Rust to also show the output of successful tests with \mintinline{shell}|cargo test -- --show-output|.
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Controlling How Tests Are Run(2)}
	\begin{itemize}
		\item Sometimes, running a full test suite can take a long time:
		\begin{itemize}
			\item If we run the tests without passing any arguments, all the tests will run in parallel
			\item 	We can pass the name of any test function to  \mintinline{shell}|cargo test| to run only that test.
			\item 	We can specify part of a test name, and any test whose name matches that value will be run.
		\end{itemize}
		\item Sometimes a few specific tests can be very time-consuming to execute, so you might want to exclude them during most runs of \mintinline{shell}|cargo test|. After  \mintinline{shell}|#[test]| we add the  \mintinline{shell}|#[ignore]| line to the test we want to exclude.   If we want to run only the ignored tests, we can use  \mintinline{shell}|cargo test -- --ignored|.
		\inputminted[fontsize=\scriptsize]{rust}{./code/test8.rs}
	\end{itemize}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Test Organization}
	\begin{itemize}
		\item The Rust community thinks about tests in terms of two main categories: \textbf{unit tests} and \textbf{integration tests}. 
		\begin{itemize}
			\item Unit tests are small and more focused, \textbf{testing one module in isolation at a time}, and \textbf{can test private interfaces}.  You’ll put unit tests in the \mintinline{shell}|src| directory in each file with the code that they’re testing. The convention is to create a module named tests in each file to contain the test functions and to annotate the module with \mintinline{rust}|#[cfg(test)]|.
			\item Integration tests are entirely external to your library and use your code in the same way any other external code would,\textbf{ using only the public interface and potentially exercising multiple modules per test}. Their purpose is to test \textbf{whether many parts of your library work together correctly}.
		\end{itemize}
	\end{itemize}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Integration test}
	We create a tests directory at the top level of our project directory, next to src. Cargo knows to look for integration test files in this directory. We can then make as many test files as we want, and Cargo will compile each of the files as an individual crate.
	
	
	\begin{columns}
		\column{0.4\textwidth}
		\begin{figure}
			\centering
			\includegraphics[width=0.8\linewidth]{img/test.png}
		\end{figure}
		\column{0.6\textwidth}
		\scriptsize
		Filename: \mintinline{shell}|tests/integration_test.rs|
		\inputminted[fontsize=\scriptsize]{rust}{./code/test9.rs}
		
		\mintinline{shell}|$ cargo test|
		
		\mintinline{shell}|$ cargo test --test integration_test|
	\end{columns}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Submodules in Integration Tests}
	For example, if we create \mintinline{shell}|tests/common.rs| and place a function named setup in it, we can add some code to \mintinline{rust}|tsetup| that we want to call from multiple test functions in multiple test files:
	
	
	\begin{columns}
		\column{0.4\textwidth}
		\begin{figure}
			\centering
			\includegraphics[width=0.8\linewidth]{img/test2.png}
		\end{figure}
		\column{0.6\textwidth}
		\scriptsize
		Filename: \mintinline{shell}|tests/common.rs|
		\inputminted[fontsize=\scriptsize]{rust}{./code/test10.rs}
	\end{columns}
	\scriptsize
	Filename: \mintinline{shell}|tests/integration_test.rs|
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/test11.rs}
	
\end{frame}

\section{An I/O Project: Building a Command Line Program}


\begin{frame}[fragile]
	\frametitle{minigrep example}
	\begin{itemize}
		\item 	We’ll make our own version of the classic command line search tool grep (globally search a regular expression and print). In the simplest use case, grep searches a specified file for a specified string. 
		\item 	The first task is to make \textbf{minigrep} accept its two command line arguments: the \textbf{file path} and \textbf{a string to search for}. That is, we want to be able to run our program with cargo run, \textbf{two hyphens to indicate the following arguments are for our program rather than for cargo}, a string to search for, and a path to a file to search in, like so: \mintinline{shell}|$ cargo run -- searchstring example-filename.txt|
	\end{itemize}
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Reading the Argument Values}
	\inputminted[fontsize=\scriptsize]{rust}{./code/grep1.rs}
	
	\inputminted[fontsize=\scriptsize]{shell}{./code/grep1.shell}
	
	Notice that the first value in the vector is the name of our binary.
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Saving the Argument Values in Variables}
	\inputminted{rust}{./code/grep2.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Reading a File}
	\inputminted{rust}{./code/grep3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Refactoring to Improve Modularity and Error Handling}
	\begin{itemize}
		\item Split your program into a \mintinline{shell}|main.rs| and a \mintinline{shell}|lib.rs| and move your \textbf{program’s logic to} \mintinline{shell}|lib.rs|.
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Refactoring (Extracting the Argument Parser)}
	\inputminted{rust}{./code/grep4.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Refactoring (Grouping Configuration Values)}
	\inputminted{rust}{./code/grep5.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{minigrep - Refactoring (Grouping Configuration Values)}
	\inputminted{rust}{./code/grep5.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Refactoring (Creating a Constructor for Config)}
	\inputminted{rust}{./code/grep6.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Refactoring (Improving the Error Message)}
	\inputminted{rust}{./code/grep7.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Refactoring (Improving the Error Message(2))}
	\inputminted{rust}{./code/grep8.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{minigrep - Refactoring (Extracting Logic from main)}
	\inputminted{rust}{./code/grep9.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Refactoring (Handling Errors Returned from run in main)}
	\inputminted{rust}{./code/grep10.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Refactoring (Splitting Code into a Library Crate)}
	Filename: \mintinline{shell}|src/lib.rs|
	\inputminted{rust}{./code/grep11.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Refactoring (Splitting Code into a Library Crate(2))}
	Filename: \mintinline{shell}|src/main.rs|
	\inputminted{rust}{./code/grep12.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Working with Environment Variables}
	\inputminted{rust}{./code/grep13.rs}

\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Working with Environment Variables (2)}
	\begin{itemize}
		\item The env::var function returns a Result that will be the successful Ok variant that contains the value of the environment variable if the environment variable is set to any value. It will return the Err variant if the environment variable is not set.
		\item 	We’re using the \mintinline{rust}|is_ok| method on the Result to check whether the environment variable is set. If the \mintinline{rust}|IGNORE_CASE|  environment variable isn’t set to anything, \mintinline{rust}|is_ok|  will return false.
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Writing Error Messages to Standard Error Instead of Standard Output}
	\begin{itemize}
		\item At the moment, we’re writing all of our output to the terminal using the \mintinline{rust}|println!| macro. In most terminals, there are two kinds of output: standard output (\mintinline{rust}|stdout|) for general information and standard error (\mintinline{rust}|stderr|) for error messages. \textbf{This distinction enables users to choose to direct the successful output of a program to a file but still print error messages to the screen}.
		\item 	To demonstrate this behavior, we’ll run the program with \mintinline{shell}|>| and the file path, output.txt, that we want to redirect the standard output stream to. (\mintinline{shell}|$ cargo run > output.txt|).
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{minigrep - Printing Errors to Standard Error}
	\inputminted{rust}{./code/grep14.rs}

\end{frame}

\section{Functional Language Features: Iterators and Closures}


\begin{frame}[fragile]
	\frametitle{Closures: Anonymous Functions that Capture Their Environment}
\begin{itemize}
	\item Rust’s closures are \textbf{anonymous functions} you can save in a variable or pass as arguments to other functions. 
	\item You can create the closure in one place and then call the closure elsewhere to evaluate it in a different context.
	\item  Unlike functions, closures \textbf{can capture values from the scope} in which they’re defined. 
	\item  We’ll demonstrate how these closure features allow for \textbf{code reuse} and \textbf{behavior customization}.
\end{itemize}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Capturing the Environment with Closures}
	\begin{itemize}
		\item Rust’s closures are \textbf{anonymous functions} you can save in a variable or pass as arguments to other functions. 
		\item You can create the closure in one place and then call the closure elsewhere to evaluate it in a different context.
		\item  Unlike functions, closures \textbf{can capture values from the scope} in which they’re defined. 
		\item  We’ll demonstrate how these closure features allow for \textbf{code reuse} and \textbf{behavior customization}.
	\end{itemize}
\inputminted{rust}{./code/closure1.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Closure Type Inference and Annotation}
	\inputminted{rust}{./code/closure.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Capturing References or Moving Ownership}
	\inputminted{rust}{./code/closure2.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Capturing References or Moving Ownership(2)}
	\inputminted{rust}{./code/closure3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Capturing References or Moving Ownership(3)}
	\inputminted{rust}{./code/closure4.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Moving Captured Values Out of Closures and the \mintinline{rust}|Fn| Traits}
	Once a closure has captured a reference or captured ownership of a value from the environment where the closure is defined, \textbf{the code in the body of the closure defines what happens to the references or values when the closure is evaluated later}. A closure body can do any of the following: 
	\begin{itemize}
		\item move a captured value out of the closure, 
		\item mutate the captured value, 
		\item neither move nor mutate the value, or capture nothing from the environment to begin with.
	\end{itemize}

The way a closure captures and handles values from the environment affects which traits the closure implements, and traits are how functions and structs can specify what kinds of closures they can use. Closures will automatically implement\textbf{ one, two, or all three of these \mintinline{rust}|Fn|  traits}, in an additive fashion, depending on how the closure’s body handles the values:
\end{frame}


\begin{frame}[fragile]
	\frametitle{Moving Captured Values Out of Closures and the \mintinline{rust}|Fn| Traits(2)}
	\begin{itemize}
		\item \mintinline{rust}|FnOnce| applies to closures that \textbf{can be called once.} \textbf{All closures implement at least this trait}, because all closures can be called. A closure that moves captured values out of its body will only implement \mintinline{rust}|FnOnce| and none of the other \mintinline{rust}|Fn| traits, because it can only be called once.
		\item  \mintinline{rust}|FnMut| applies to closures that don’t move captured values out of their body, but that \textbf{might mutate the captured values}. These closures can be called more than once.
		\item 	\mintinline{rust}|Fn| applies to closures that don’t move captured values out of their body and that don’t mutate captured values, as well as \textbf{closures that capture nothing from their environment}. These closures can be called more than once without mutating their environment, which is important in cases such as calling a closure multiple times concurrently.
	\end{itemize}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Moving Captured Values Out of Closures and the \mintinline{rust}|Fn| Traits(3)}
\begin{figure}
	\centering
	\includegraphics[width=1\linewidth]{img/closure.png}
\end{figure}

\end{frame}

\begin{frame}[fragile]
	\frametitle{Processing a Series of Items with Iterators}
	\begin{itemize}
		\item The iterator pattern allows you to perform some task on a sequence of items in turn.
		\item 	In Rust, iterators are \textbf{lazy}, meaning they have no effect until you call methods that consume the iterator to use it up. 
		\inputminted{rust}{./code/iterator.rs}
		\item 	All iterators implement a trait named \mintinline{rust}|Iterator| that is defined in the standard library.
	\end{itemize}


\end{frame}

\begin{frame}[fragile]
	\frametitle{The Iterator Trait and the next Method}
	\inputminted[fontsize=\scriptsize]{rust}{./code/iterator2.rs}
	
		\inputminted[fontsize=\scriptsize]{rust}{./code/iterator3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{The Iterator Trait and the next Method(2)}
	\inputminted[fontsize=\scriptsize]{rust}{./code/iterator3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Consuming Adaptors and Iterator Adaptors}
	Methods that call next are called \textbf{consuming adaptors}, because calling them uses up the iterator. 
	
		\inputminted[fontsize=\scriptsize]{rust}{./code/iterator4.rs}
		
		
		\textbf{Iterator adaptors }are methods defined on the Iterator trait that don’t consume the iterator. Instead, they \textbf{produce different iterators} by changing some aspect of the original iterator.
\end{frame}

\begin{frame}[fragile]
	\frametitle{Consuming Adaptors and Iterator Adaptors(2)}

	\inputminted{rust}{./code/iterator5.rs}
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{Improving Our I/O Project, removing clone Using Iterator}
	
	\inputminted{rust}{./code/iterator6.rs}
	
\end{frame}

\begin{frame}[fragile]
	\frametitle{Improving Our I/O Project, removing clone Using Iterator(2)}
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/iterator7.rs}
	
\end{frame}
 
 \begin{frame}[fragile]
 	\frametitle{Improving Our I/O Project, removing clone Using Iterator(3)}
 	
 	\inputminted[fontsize=\scriptsize]{rust}{./code/iterator8.rs}
 	
 \end{frame}

 \begin{frame}[fragile]
	\frametitle{Improving Our I/O Project, removing clone Using Iterator(4)}
	\begin{itemize}
		\item We can write this code in a more concise way using iterator adaptor methods. Doing so also lets us avoid having a \textbf{mutable intermediate results vector}. The functional programming style prefers to minimize the amount of mutable state to make code clearer. \textbf{Removing the mutable state might enable a future enhancement to make searching happen in parallel}, because we wouldn’t have to manage concurrent access to the results vector. 
		\item 	To determine whether to use loops or iterators, you need to know which implementation is faster: \textbf{The iterator version was slightly faster! }(for more info see \href{https://doc.rust-lang.org/book/ch13-04-performance.html}{here}).
	\end{itemize}
\end{frame} 
 
\section{More About Cargo and Crates.io}

\begin{frame}[fragile]
	\frametitle{Customizing Builds with Release Profiles}

\inputminted{shell}{./code/profile.shell}

Filename: \mintinline{shell}|Cargo.toml| 

\inputminted{toml}{./code/profile2.toml}

\end{frame} 



\begin{frame}[fragile]
	\frametitle{Publishing a Crate to \mintinline{shell}|Crates.io|}
	
	\begin{itemize}
		\item The crate registry at \mintinline{shell}|Crates.io| distributes the source code of your packages, so it primarily hosts code that is open source.
		\item 	Accurately documenting your packages will help other users know how and when to use them, so it’s worth investing the time to write documentation. 
		\item 	Documentation comments use \textbf{three slashes, ///}, instead of two and \textbf{support Markdown notation} for formatting the text.
	\end{itemize}
\end{frame} 


\begin{frame}[fragile]
	\frametitle{Making Useful Documentation Comments}
	\inputminted{rust}{./code/documentation.rs}
	
	For convenience, running \mintinline{rust}|cargo doc --open | will build the HTML for your current crate’s documentation (as well as the documentation for all of your crate’s dependencies) and open the result in a web browser.
\end{frame} 


\begin{frame}[fragile]
	\frametitle{Making Useful Documentation Comments(2)}
	\inputminted{rust}{./code/documentation.rs}
	
	For convenience, running \mintinline{rust}|cargo doc --open | will build the HTML for your current crate’s documentation (as well as the documentation for all of your crate’s dependencies) and open the result in a web browser.
\end{frame} 

\begin{frame}[fragile]
\frametitle{Making Useful Documentation Comments(3)}

\begin{figure}
	\centering
	\includegraphics[width=0.99\linewidth]{img/trpl14-01}
\end{figure}

\end{frame} 

\begin{frame}[fragile]
\frametitle{Commenting Contained Items}
The style of doc comment \mintinline{rust}|//!| adds documentation to the item that contains the comments rather than to the items following the comments. We typically use these doc comments inside the crate root file ( \mintinline{shell}|src/lib.rs| by convention) or inside a module to document the crate or the module as a whole.

\inputminted[fontsize=\scriptsize]{rust}{./code/documentation2.rs}

\end{frame} 



\begin{frame}[fragile]
	\frametitle{Making Useful Documentation Comments(3)}
	
	\begin{figure}
		\centering
		\includegraphics[width=0.99\linewidth]{img/trpl14-02}
	\end{figure}
	
\end{frame} 


\begin{frame}[fragile]
	\frametitle{Setting Up a Crates.io Account and Publish}
	\begin{itemize}
		\item Before you can publish any crates, you need to create an account on \mintinline{shell}|crates.io| and \textbf{get an API token}. 
		\item 	Once you’re logged in, visit your account settings at \textbf{https://crates.io/me/} and retrieve your API key. 
		\item  Then run the \mintinline{shell}|cargo login| command with your API key, like this: \mintinline{shell}|cargo login abcdefghijklmnopqrstuvwxyz012345|.
		\item Before publishing\mintinline{shell}|cargo publish|, you’ll need to add some metadata in the \mintinline{toml}|[package]| section of the crate’s \mintinline{shell}|Cargo.toml| file.
		\inputminted[fontsize=\scriptsize]{toml}{./code/cargo3.toml}
	\end{itemize}
	
\end{frame} 

\begin{frame}[fragile]
	\frametitle{Cargo Workspaces}
	 \begin{itemize}
	 	\item As your project develops, you might find that the library crate continues to get bigger and you want to split your package further into multiple library crates.
	 	\item 	 Cargo offers a feature called \textbf{workspaces} that can help manage multiple related packages that are developed in tandem.
	 	\item  Change the top-level \mintinline{rust}|Cargo.toml| to specify the \mintinline{rust}|add_one| path in the members list:
	 	
	 	\begin{columns}
	 		\column{0.4\textwidth}
	 		\inputminted{toml}{./code/cargo4.toml}
	 		\column{0.6\textwidth}
	 		\begin{figure}
	 			\centering
	 			\includegraphics[width=0.5\textwidth]{img/workspace}
	 		\end{figure}
	 	\end{columns}
	 \end{itemize}
\end{frame} 

\section{Smart Pointers}



\begin{frame}[fragile]
	\frametitle{Smart Pointers}
	\begin{itemize}
		\item A \textbf{pointer} is a general concept for a variable that contains an address in memory. 
		\item 	The most common kind of pointer in Rust is a \textbf{reference}, which are indicated by the  \mintinline{rust}|&|  symbol and borrow the value they point to. 
		\item 	\textbf{Smart pointers}, on the other hand, are \textbf{data structures} that act like a pointer but also have additional metadata and capabilities. The concept of smart pointers isn’t unique to Rust: smart pointers originated in C++ and exist in other languages as well.
		\item 	Rust has a \textbf{variety of smart pointers} defined in the standard library that provide functionality beyond that provided by references.
		\item 	Rust, with its concept of ownership and borrowing, has an additional difference between references and smart pointers: \textbf{while references only borrow data, in many cases, smart pointers own the data they point to}.
	\end{itemize}
\end{frame} 


\begin{frame}[fragile]
	\frametitle{Smart Pointers (2)}
\begin{itemize}
	\item  \mintinline{rust}|String| and \mintinline{rust}|Vec<T>| are types count as smart pointers because they own some memory and allow you to manipulate it. They also have metadata and extra capabilities or guarantees. 
	\item  Smart pointers are usually implemented using structs. Unlike an ordinary struct, smart pointers implement the \mintinline{rust}|Deref| and \mintinline{rust}|Drop| traits. The \mintinline{rust}|Deref| trait allows an instance of the smart pointer struct to behave \textbf{like a reference} so you can write your code to work with either references or smart pointers. The \mintinline{rust}|Drop| trait allows you to customize the code that’s run when an instance of the smart pointer goes out of scope. 
	\item  the most common smart pointers in the standard library:
	\begin{itemize}
		\item \mintinline{rust}|Box<T>| for allocating values on the heap
		\item 	\mintinline{rust}|Rc<T>|, a reference counting type that enables multiple ownership
		\item 	\mintinline{rust}|Ref<T>| and \mintinline{rust}|RefMut<T>|, accessed through \mintinline{rust}|RefCell<T>|, a type that enforces the borrowing rules at runtime instead of compile time
	\end{itemize}
\end{itemize}
\end{frame} 




\begin{frame}[fragile]
	\frametitle{Using \mintinline{rust}|Box<T>| to Point to Data on the Heap}
	\begin{itemize}
		\item The most straightforward smart pointer is a box, whose type is written \mintinline{rust}|Box<T>|. Boxes allow you to \textbf{store data on the heap} rather than the stack. \textbf{What remains on the stack is the pointer to the heap data}.
		\item 	Boxes \textbf{don’t have performance overhead}, other than storing their data on the heap instead of on the stack. But they don’t have many extra capabilities either. You’ll use them most often in these situations:
			\begin{itemize}
			\item When you \textbf{have a type whose size can’t be known at compile time} and you \textbf{want to use a value of that type in a context that requires an exact size}
			\item 	When you \textbf{have a large amount of data and you want to transfer ownership but ensure the data won’t be copied} when you do so
			\item 	When you want to own a value and you care only that it’s a type that implements a particular trait rather than being of a specific type (known as a \textbf{trait object}, we learn later)
		\end{itemize}
	\end{itemize}

\end{frame} 


\begin{frame}[fragile]
	\frametitle{Using a \mintinline{rust}|Box<T>| to Store Data on the Heap}
	\inputminted{rust}{./code/smart1.rs}
\end{frame} 



\begin{frame}[fragile]
	\frametitle{Enabling Recursive Types with Boxes}
	A value of recursive type can have another value of the same type as part of itself. Recursive types pose an issue because at compile time Rust needs to know how much space a type takes up. However, the nesting of values of recursive types could theoretically continue infinitely, so Rust can’t know how much space the value needs. Because boxes have a known \textbf{size}, we can enable recursive types.
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/smart2.rs}
\end{frame} 

\begin{frame}[fragile]
	\frametitle{Implementing the \mintinline{rust}|Deref| trait allows you to customize the behavior of the dereference operator *}
	Implementing the Deref trait allows you to customize the behavior of the dereference operator \mintinline{rust}|*| (not to be confused with the multiplication or glob operator). By implementing \mintinline{rust}|Deref| in such a way that a smart pointer can be treated like a regular reference, you can write code that operates on references and use that code with smart pointers too.
	
	\begin{columns}
		\column{0.5\textwidth}
		\inputminted{rust}{./code/smart3.rs}
		\column{0.5\textwidth}
		\inputminted{rust}{./code/smart4.rs}
	\end{columns}

\end{frame} 

 \begin{frame}[fragile]
 	\frametitle{Defining Our Own Smart Pointer}
 	\inputminted[fontsize=\scriptsize]{rust}{./code/smart5.rs}
 \end{frame} 

\begin{frame}[fragile]
	\frametitle{Implicit Deref Coercions with Functions and Methods}
	\textbf{Deref coercion} converts a reference to a type that implements the \mintinline{rust}|Deref| trait into a reference to another type. 
	\begin{itemize}
		\item For example, deref coercion can convert \mintinline{rust}|&String| to \mintinline{rust}|&str| because String implements the \mintinline{rust}|Deref| trait such that it returns \mintinline{rust}|&str|. 
	\end{itemize}
	\inputminted{rust}{./code/smart6.rs}
\end{frame} 

\begin{frame}[fragile]
	\frametitle{Running Code on Cleanup with the  \mintinline{rust}|Drop| Trait}
	The \mintinline{rust}|Drop| trait lets you customize what happens when a value is about to go out of scope.
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/smart7.rs}
\end{frame} 



\begin{frame}[fragile]
	\frametitle{\mintinline{rust}|Rc<T>|, the Reference Counted Smart Pointer}
	\begin{itemize}
		\item In the majority of cases, ownership is clear: you know exactly which variable owns a given value. However, there are cases when\textbf{ a single value might have multiple owners}. For example, in graph data structures, multiple edges might point to the same node, and that node is conceptually owned by all of the edges that point to it. 
		\item 	You have to enable \textbf{multiple ownership explicitly }by using the Rust type \mintinline{rust}|Rc<T>|, which is an abbreviation for reference counting. \textbf{The \mintinline{rust}|Rc<T>| type keeps track of the number of references to a value to determine whether or not the value is still in use. If there are zero references to a value, the value can be cleaned up without any references becoming invalid}.
	\end{itemize}
\end{frame} 


\begin{frame}[fragile]
	\frametitle{Using \mintinline{rust}|Rc<T>| to Share Data}
	\begin{figure}
		\centering
		\includegraphics[width=0.99\linewidth]{img/graph}
	\end{figure}
	
\end{frame} 


\begin{frame}[fragile]
	\frametitle{Using \mintinline{rust}|Rc<T>| to Share Data(2)}
	\inputminted{rust}{./code/smart8.rs}
	
\end{frame} 

\begin{frame}[fragile]
	\frametitle{Using \mintinline{rust}|Rc<T>| to Share Data(3)}
	\inputminted{shell}{./code/smart8.shell}
	
\end{frame} 

\begin{frame}[fragile]
	\frametitle{Using \mintinline{rust}|Rc<T>| to Share Data(4)}
	\inputminted{rust}{./code/smart9.rs}
	
\end{frame} 

\begin{frame}[fragile]
	\frametitle{\mintinline{rust}|RefCell<T>| and the Interior Mutability Pattern}
	\textbf{Interior mutability} is a \textbf{design pattern} in Rust that allows you \textbf{to mutate data even when there are immutable references to that data}.
	normally, this action is disallowed by the borrowing rules. 
	\begin{itemize}
		\item To mutate data,\textbf{ the pattern uses unsafe code inside a data structure }to bend Rust’s usual rules that govern mutation and borrowing. 
		\item Unsafe code indicates to the compiler that we’re checking the rules manually instead of relying on the compiler to check them for us.
		\item \textbf{Enforcing Borrowing Rules at Runtim}e with \mintinline{rust}|RefCell<T>|.
	\end{itemize}
\end{frame} 

\begin{frame}[fragile]
	\frametitle{Interior mutability with \mintinline{rust}|Cell|}
	\inputminted[fontsize=\scriptsize]{rust}{./code/smart10.rs}
\end{frame} 

\begin{frame}[fragile]
	\frametitle{Interior mutability with  \mintinline{rust}|RefCell| (reference cell) }
	A \mintinline{rust}|RefCell| is like a \mintinline{rust}|Cell| but uses references instead of copies.
	\inputminted[fontsize=\scriptsize]{rust}{./code/smart11.rs}
\end{frame} 

\begin{frame}[fragile]
	\frametitle{Interior mutability example}
	\inputminted[fontsize=\scriptsize]{rust}{./code/smart12.rs}
\end{frame} 

\begin{frame}[fragile]
	\frametitle{Reference Cycles Can Leak Memory}
	Rust’s memory safety guarantees make it difficult, but not impossible, to accidentally \textbf{create memory that is never cleaned up} (known as a \textbf{memory leak}). 
	\begin{itemize}
		\item Preventing memory leaks entirely is not one of Rust’s guarantees, meaning \textbf{memory leaks are memory safe in Rust}. 
	\end{itemize}

	We can see that Rust allows memory leaks by using \mintinline{rust}|Rc<T>| and \mintinline{rust}|RefCell<T>|:\textbf{ it’s possible to create references where items refer to each other in a cycle}. This creates memory leaks because the reference count of each item in the cycle will never reach 0, and the values will never be dropped.
\end{frame} 

\begin{frame}[fragile]
	\frametitle{Creating a Reference Cycle}
	\inputminted[fontsize=\scriptsize]{rust}{./code/smart13.rs}
\end{frame} 

\begin{frame}[fragile]
	\frametitle{Creating a Reference Cycle (2)}
	\inputminted[fontsize=\scriptsize]{rust}{./code/smart14.rs}
\end{frame} 


\begin{frame}[fragile]
	\frametitle{Creating a Reference Cycle (3)}
	\begin{figure}
		\centering
		\includegraphics[width=0.99\linewidth]{img/trpl15-04}
	\end{figure}
	
\end{frame} 

\begin{frame}[fragile]
	\frametitle{Preventing Reference Cycles: Turning an \mintinline{rust}|Rc<T>|  into a \mintinline{rust}|Weak<T>|}
	\inputminted[fontsize=\scriptsize]{rust}{./code/smart15.rs}
\end{frame} 


\begin{frame}[fragile]
	\frametitle{Adding a Reference from a Child to Its Parent}
	\inputminted[fontsize=\scriptsize]{rust}{./code/smart16.rs}
\end{frame} 


\section{Fearless Concurrency}

\begin{frame}[fragile]
	\frametitle{Fearless concurrency}
	\begin{itemize}
		\item Handling \textbf{concurrent programming safely and efficiently }is another of Rust’s major goals. 
		\item \textbf{Concurrent programming}, where different parts of a program execute independently, and \textbf{parallel programming}, where different parts of a program execute at the same time, are becoming increasingly important as more computers take advantage of their multiple processors. 
		\item 	Historically, \textbf{programming in these contexts has been difficult and error prone}: Rust hopes to change that.
		\item \textbf{Fearless concurrency} allows you to write code that is \textbf{free of subtle bugs} and is easy to refactor without introducing new bugs.
		Using Threads to Run Code Simultaneously
	\item In most current operating systems, an executed program’s code is run in a \textbf{process}. Within a program, you can also have independent parts that run simultaneously. The features that run these independent parts are called \textbf{threads}. 
	\end{itemize}
\end{frame} 


\begin{frame}[fragile]
	\frametitle{Concurrent Programming Problems}
\begin{itemize}
	\item \textbf{Race conditions}, where threads are accessing data or resources in an inconsistent order
	\item \textbf{Deadlocks}, where two threads are waiting for each other, preventing both threads from continuing
	\item Bugs that happen only in certain situations and are \textbf{hard to reproduce} and fix reliably
\end{itemize}

Rust attempts to mitigate the negative effects of using threads.
\end{frame} 

\begin{frame}[fragile]
	\frametitle{Creating a New Thread with spawn}
	\inputminted{rust}{./code/thread1.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Using move Closures with Threads}
	\inputminted{rust}{./code/thread2.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Using move Closures with Threads(2)}
	\inputminted{shell}{./code/thread2.shell}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Using move Closures with Threads(3)}
	A scenario that’s more likely to have a reference to \mintinline{rust}|v| that won’t be valid:
	\inputminted{rust}{./code/thread3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Using move Closures with Threads(4)}
	\inputminted{rust}{./code/thread4.rs}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Using Message Passing to Transfer Data Between Threads}
	\begin{itemize}
		\item One increasingly \textbf{popular approach} to ensuring \textbf{safe concurrency} is \textbf{message passing}, where threads or actors communicate by sending each other messages containing data. 
		\item 	From the \textbf{Go language} documentation: “\textbf{Do not communicate by sharing memory; instead, share memory by communicating}.”
		\item 	To accomplish message-sending concurrency, Rust's standard library provides an implementation of channels. A \textbf{channel} is a general programming \textbf{concept by which data is sent from one thread to another}.
		\item A channel has two halves: a transmitter and a receiver. 
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Using Message Passing Example}
	\inputminted{rust}{./code/thread5.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Channels and Ownership Transference}
	\inputminted{rust}{./code/thread6.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Channels and Ownership Transference}
	\inputminted{shell}{./code/thread6.shell}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Creating Multiple Producers by Cloning the Transmitter}
	
	
	\begin{columns}
		\column{0.5\textwidth}
		\inputminted{rust}{./code/thread7.rs}
		
		\column{0.5\textwidth}
		\inputminted[firstnumber=15]{rust}{./code/thread8.rs}
	\end{columns}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Shared-State Concurrency}
	\begin{itemize}
		\item \textbf{Message passing} is a fine way of handling concurrency, but\textbf{ it’s not the only one}. Another method would be for multiple \textbf{threads to access the same shared data}.
		\item 	In a way, \textbf{channels} in any programming language are \textbf{similar to single ownership}, because once you transfer a value down a channel, you should no longer use that value. \textbf{Shared memory} concurrency is like \textbf{multiple ownership}: multiple threads can access the same memory location at the same time. 
	\end{itemize}
\end{frame}


\section{Object-Oriented Programming Features of Rust}

\begin{frame}[fragile]
	\frametitle{Objects Contain Data and Behavior}
	 \begin{block}{The book Design Patterns (The Gang of Four): }
		Object-oriented programs are made up of objects. An object packages both \textbf{data} and the \textbf{procedures that operate on that data}. The procedures are typically called methods or operations.
	\end{block}
	
	\begin{itemize}
		\item Using this definition, \textbf{Rust is object-oriented}: structs and enums have data, and impl blocks provide methods on structs and enums.
	\end{itemize}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Encapsulation that Hides Implementation Details}
	
	\begin{itemize}
		\item 	Another aspect commonly associated with OOP is the idea of encapsulation, which means that \textbf{the implementation details of an object aren’t accessible to code using that object}.
		\item  Therefore, the only way to interact with an object is through its \textbf{public} API.
	\end{itemize}

\begin{columns}
	\column{0.5\textwidth}
	\inputminted[fontsize=\scriptsize]{rust}{./code/oop1.rs}
	\column{0.5\textwidth}
	\inputminted[firstnumber=6, fontsize=\scriptsize]{rust}{./code/oop2.rs}
\end{columns}

\end{frame}

	
	\begin{frame}[fragile]
		\frametitle{Inheritance}
		
		\begin{itemize}
			\item Inheritance enables a child type to be used in the same places as the parent type. This is also called polymorphism, which means that you can \href{https://en.wikipedia.org/wiki/Liskov_substitution_principle}{\textbf{\underline{substitute}}} multiple objects for each other at runtime if they share certain characteristics.
			\item 	Inheritance is a mechanism whereby an object can inherit elements from another object’s definition, thus gaining the parent object’s data and behavior without you having to define them again (\textbf{Code Sharing and Reuse}).
		
				\item 	If a language must have inheritance to be an object-oriented language, then \textbf{Rust is not one}.
				\item 	You can do this in a \textbf{limited way} in Rust code using default \textbf{trait} method implementations.
			
			
		\end{itemize}
	\end{frame}
	
	
	
	\begin{frame}[fragile]
		\frametitle{Defining a Trait for Common Behavior}
		\inputminted[fontsize=\scriptsize]{rust}{./code/oop3.rs}
	\end{frame}


	\begin{frame}[fragile]
	\frametitle{Implementing the Trait}
	\begin{columns}
		\column{0.5\textwidth}
		\inputminted[fontsize=\scriptsize]{rust}{./code/oop4.rs}
		\column{0.5\textwidth}
		\inputminted[fontsize=\scriptsize]{rust}{./code/oop5.rs}
	\end{columns}
\end{frame}


	\begin{frame}[fragile]
	\frametitle{Using trait objects to store values of different types that implement the same trait}
		\inputminted[fontsize=\scriptsize]{rust}{./code/oop6.rs}
\end{frame}


	\begin{frame}[fragile]
	\frametitle{Trait Objects Perform Dynamic Dispatch}
	\begin{itemize}
		\item  In the “Performance of Code Using Generics”, the monomorphization process performed by the \textbf{compiler} when we use \textbf{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 \textbf{static dispatch}, which is when the compiler knows what method you’re calling at compile time (\textbf{faster}). 
		\item 	 This is opposed to \textbf{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 \textbf{runtime} will figure out which method to call (extra \textbf{flexibility}).
	\end{itemize}
\end{frame}


\section{Patterns and Matching}


\begin{frame}[fragile]
	\frametitle{Patterns}
	\begin{itemize}
		\item Using \textbf{patterns} in conjunction with match expressions and other constructs gives you more control over a program’s control flow.
		\item 	Some example patterns include \mintinline{rust}|x|, \mintinline{rust}|(a, 3)|, and \mintinline{rust}|Some(Color::Red)|. In the contexts in which patterns are valid, these components describe the shape of data. 
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Patterns in match Arms}
	\inputminted{rust}{./code/match1.rs}
	
	\begin{itemize}
		\item The patterns in this match expression are the None and Some(i) on the left of each arrow.
		\item 	One requirement for match expressions is that they need to be exhaustive in the sense that all possibilities for the value in the match expression must be accounted for.
	\end{itemize}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Patterns in Conditional if let Expressions}
	\inputminted{rust}{./code/pattern1.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Patterns in while let, for Loops, and let Expressions}
	\inputminted{rust}{./code/pattern2.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Patterns in Function Parameters}
	\inputminted{rust}{./code/pattern3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Refutability: Whether a Pattern Might Fail to Match}
	\inputminted{rust}{./code/pattern4.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Matching Literals}
	\inputminted{rust}{./code/pattern5.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Matching Named Variables}
	\inputminted{rust}{./code/pattern7.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Multiple Patterns}
	\inputminted{rust}{./code/pattern8.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Matching Ranges of Values with \mintinline{rust}|..=|}
	\inputminted{rust}{./code/pattern9.rs}
\end{frame}




\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Destructuring Structs}
	\inputminted[fontsize=\scriptsize]{rust}{./code/pattern10.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Destructuring Enums}
	\inputminted[fontsize=\scriptsize]{rust}{./code/pattern11.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Destructuring Nested Structs and Enums}
	\inputminted[fontsize=\scriptsize]{rust}{./code/pattern12.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Destructuring Structs and Tuples}
	\inputminted[fontsize=\scriptsize]{rust}{./code/pattern13.rs}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Ignoring Values in a Pattern}
	\inputminted[fontsize=\scriptsize]{rust}{./code/pattern14.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Ignoring an Unused Variable by Starting Its Name with \mintinline{rust}|_|}
	\inputminted{rust}{./code/pattern15.rs}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Ignoring Remaining Parts of a Value with \mintinline{rust}|..|}
	\inputminted{rust}{./code/pattern16.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Extra Conditionals with Match Guards}
	\inputminted{rust}{./code/pattern17.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Binding}
	\inputminted{rust}{./code/pattern18.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Binding(2)}
	\inputminted{rust}{./code/pattern19.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Pattern Syntax, Binding(3)}
	\inputminted{rust}{./code/pattern20.rs}
\end{frame}


\section{Advanced Features}

\begin{frame}[fragile]
	\frametitle{Unsafe Rust}
	\begin{itemize}
		\item All the code we’ve discussed so far has had Rust’s \textbf{memory safety} guarantees enforced at \textbf{compile time}.
		\item 	Rust has a second language hidden inside it that doesn’t enforce these memory safety guarantees: it’s called unsafe Rust and works just like regular Rust, but gives us extra \textbf{superpowers}.
		\begin{itemize}
			\item Unsafe Rust exists because, by nature, \textbf{static analysis is conservative}. 
			\item 	Sometime, your code might be okay, if the Rust compiler doesn’t have enough information to be confident, it will reject the code. In these cases, you can use unsafe code to \textbf{tell the compiler}, “\textbf{Trust me, I know what I’m doing.}” 
			\item 	If you use unsafe code incorrectly, problems can occur due to memory unsafety, such as null pointer dereferencing.
		\end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Unsafe Superpowers}
	To switch to unsafe Rust, use the \mintinline{rust}|unsafe| keyword and then start a new block that holds the unsafe code.\textbf{ You can take five actions in unsafe Rust that you can’t in safe Rust}, which we call unsafe superpowers. Those superpowers include the ability to:
	
	\begin{itemize}
		\item Dereference a raw pointer
		\item 	Call an unsafe function or method
		\item 	Access or modify a mutable static variable
		\item 	Implement an unsafe trait
		\item 	Access fields of unions
	\end{itemize}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Dereferencing a Raw Pointer}
	Compiler ensures \textbf{references are always valid}. Unsafe Rust has two new types called \textbf{raw pointers that are similar to references}. As with references, r\textbf{aw pointers can be immutable or mutable} and are written as \mintinline{rust}|*const T| and \mintinline{rust}|*mut T| , respectively. The \textbf{asterisk} isn’t the dereference operator; \textbf{it’s part of the type name}. In the context of raw pointers, immutable means that the pointer can’t be directly assigned to after being dereferenced.
	
	\inputminted{rust}{./code/unsafe1.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Calling an Unsafe Function or Method}
	\inputminted{rust}{./code/unsafe2.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Creating a Safe Abstraction over Unsafe Code}
	\inputminted[fontsize=\scriptsize]{rust}{./code/unsafe3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Creating a Safe Abstraction over Unsafe Code(2)}
	\inputminted[fontsize=\scriptsize]{rust}{./code/unsafe4.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Using extern Functions to Call External Code}
	\inputminted{rust}{./code/unsafe5.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Calling Rust Functions from Other Languages}
	We also need to add a \mintinline{rust}|#[no_mangle] | annotation to tell the Rust compiler not to mangle the name of this function. \textbf{Mangling is when a compiler changes the name we’ve given a function to a different name} that contains more information for other parts of the compilation process to consume but is less human readable. Every programming language compiler mangles names slightly differently, so for a Rust function to be nameable by other languages, we must disable the Rust compiler’s name mangling.
	
	\inputminted{rust}{./code/unsafe6.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Modifying a Mutable Static Variable}
	\inputminted{rust}{./code/unsafe7.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Accessing Fields of a Union}
	The final action that works only with unsafe is accessing fields of a union. A union is similar to a struct, but only one declared field is used in a particular instance at one time. Unions are primarily used to interface with unions in C code. Accessing union fields is unsafe because Rust can’t guarantee the type of the data currently being stored in the union instance. 
	
	\inputminted{rust}{./code/unsafe8.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Advanced Traits}
	\begin{itemize}
		\item Specifying Placeholder Types in Trait Definitions with Associated Types
		\item 	Default Generic Type Parameters and Operator Overloading
		\item 	Fully Qualified Syntax for Disambiguation: Calling Methods with the Same Name
		\item 	Using the Newtype Pattern to Implement External Traits on External Types
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Specifying Placeholder Types in Trait Definitions with Associated Types}
	\inputminted[fontsize=\scriptsize]{rust}{./code/iter1.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Associated Types vs generics}
	\begin{itemize}
		\item The difference is that when using generics, \textbf{we must annotate the types in each implementation}
		\item 	 We could have multiple implementations of Iterator for Counter. In other words, when a trait has a generic parameter, \textbf{it can be implemented for a type multiple times}, changing the concrete types of the generic type parameters each time. 
		\item 	 When we use the \mintinline{rust}|next|  method on Counter, we would have to provide type annotations to indicate which implementation of Iterator we want to use.
		\item 	With associated types, we don’t need to annotate types because we can’t implement a trait on a type multiple times. 
	\end{itemize}
	
	\inputminted{rust}{./code/iter2.rs}
\end{frame}




\begin{frame}[fragile]
	\frametitle{Default Generic Type Parameters and Operator Overloading}
	\inputminted[fontsize=\fontsize{8.5pt}{8.5pt}]{rust}{./code/iter3.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Default Generic Type Parameters and Operator Overloading(2)}
	The default generic type in this code is within the Add trait. Here is its definition:
	
	\inputminted{rust}{./code/iter4.rs}
	
	When we implemented Add for Point, we used the default for Rhs because we wanted to add two Point instances. 
\end{frame}

\begin{frame}[fragile]
	\frametitle{Default Generic Type Parameters and Operator Overloading(3)}
	Let’s look at an example of implementing the Add trait where we want to customize the Rhs type rather than using the default.
	
	\inputminted{rust}{./code/iter5.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Fully Qualified Syntax for Disambiguation: Calling Methods with the Same Name}
	\begin{columns}
		\column{0.5\textwidth}
		\inputminted[fontsize=\tiny]{rust}{./code/iter6.rs}
		\column{0.5\textwidth}
		\inputminted[fontsize=\tiny]{rust}{./code/iter7.rs}
	\end{columns}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Fully Qualified Syntax for Disambiguation: Calling Methods with the Same Name(2)}
	\inputminted[fontsize=\fontsize{8.5pt}{8.5pt}]{rust}{./code/iter8.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Using Supertraits to Require One Trait’s Functionality Within Another Trait}
	Sometimes, you might write a trait definition that depends on another trait: for a type to implement the first trait, you want to \underline{require} that type to also implement the second trait. 
	
	\inputminted[fontsize=\fontsize{8.5pt}{8.5pt}]{rust}{./code/iter9.rs}
	
\end{frame}


\begin{frame}[fragile]
	\frametitle{Using Supertraits to Require One Trait’s Functionality Within Another Trait (2)}
	\inputminted[firstnumber=17]{rust}{./code/iter10.rs}
\end{frame}
	
	
	
	
	\begin{frame}[fragile]
		\frametitle{Using the Newtype Pattern to Implement External Traits on External Types}
		\begin{itemize}
			\item The \textbf{orphan rule} that states we’re only allowed to implement a trait on a type if either the trait or the type are local to our crate. It’s possible to get around this restriction using the \textbf{newtype pattern}, which involves creating a new type in a tuple struct. 
			\item 		 Newtype is a term that \textbf{originates} from the \textbf{Haskell} programming language. 
			\item 		 There is \textbf{no runtime performance penalty }for using this pattern, and the wrapper type is elided at compile time.
		\end{itemize}
	\end{frame}

\begin{frame}[fragile]
	\frametitle{Using the Newtype Pattern to Implement External Traits on External Types(2)}
	
	\inputminted{rust}{./code/iter11.rs}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Creating Type Synonyms with Type Aliases}
	Rust provides the ability to declare a type alias to give an existing type another name.
	
	\inputminted{rust}{./code/type1.rs}
	
	The alias type is a synonym for another type;  alias type  \textbf{is not a separate, new type}.
	
	\inputminted{rust}{./code/type2.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Creating Type Synonyms with Type Aliases(2)}
	Unlike Kilometers, the Millimeters and Meters types we earlier created, are a separate, new type. 
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/type3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{The main use case for type synonyms is to reduce repetition}
	
	\inputminted{rust}{./code/type4.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{The Never Type that Never Returns}
	
	\inputminted{rust}{./code/type5.rs}
	
	This code is read as “\textbf{the function bar returns never.}” Functions that return never are called diverging functions. We can’t create values of the type ! so bar can never possibly return.
\end{frame}


\begin{frame}[fragile]
	\frametitle{Dynamically Sized Types and the Sized Trait}
	\begin{itemize}
		\item Rust \textbf{needs to know certain details about its types}, such as \textbf{how much space} to allocate for a value of a particular type. 
		\item 	This leaves one corner of its type system a little confusing at first: the concept of \textbf{dynamically sized types}.
		\item 	Sometimes referred to as \textbf{DST}s or \textbf{unsized types}, these types let us write code using values whose size we can know only at runtime.
		 \begin{itemize}
		 	\item That’s right, not \mintinline{rust}|&str|, but \mintinline{rust}|str| on its own, is a DST. We can’t know how long the string is until runtime, meaning we can’t create a variable of type \mintinline{rust}|str|, nor can we take an argument of type \mintinline{rust}|str|.
		 	\item 	 We can combine \mintinline{rust}|str| with all kinds of pointers: for example, \mintinline{rust}|Box<str>| or \mintinline{rust}|Rc<str>|. In fact, you’ve seen this before but with a different dynamically sized type: traits. Every trait is a dynamically sized type.
		 \end{itemize}
	\end{itemize}
	 
\end{frame}

\begin{frame}[fragile]
	\frametitle{Dynamically Sized Types and the Sized Trait(2)}
To work with DSTs, Rust provides the \textbf{Sized trait }to \textbf{determine whether or not a type’s size is known at compile time}. \textbf{This trait is automatically implemented} for everything \textbf{whose size is known at compile time}. In addition, Rust\textbf{ implicitly adds a bound on Sized to every generic function}. That is, a generic function definition like this:
	
	\inputminted{rust}{./code/type6.rs}
	
\end{frame}


\begin{frame}[fragile]
	\frametitle{Dynamically Sized Types and the Sized Trait(3)}
	By default, generic functions will work only on types that have a known size at compile time. However, you can use the following special syntax to relax this restriction:
	
	\inputminted{rust}{./code/type7.rs}
	
	\scriptsize
	\begin{itemize}
		\item A trait bound on  \mintinline{rust}|?Sized| means “\textbf{T may or may not be Sized}” and this notation \textbf{overrides the default that generic types must have a known size at compile time}. \textbf{The \mintinline{rust}|?Trait| syntax with this meaning is only available for Sized, not any other traits}.
		\item 	Also note that we switched the type of the t parameter from \mintinline{rust}|T| to \mintinline{rust}|&T|. Because the type might not be Sized, we need to use it behind some kind of pointer. In this case, we’ve chosen a reference.
	\end{itemize}
	
\end{frame}



\begin{frame}[fragile]
	\frametitle{Function Pointers}
Functions coerce to the type \mintinline{rust}|fn| (with \textbf{a lowercase f}), not to be confused with the \mintinline{rust}|Fn| \textbf{closure trait}. The \mintinline{rust}|fn| type is called a function pointer. Passing functions with function pointers will allow you to use functions as arguments to other functions.

	\inputminted{rust}{./code/fn1.rs}

\end{frame}


\begin{frame}[fragile]
	\frametitle{Returning Closures}
	Closures are represented by traits, which means you can’t return closures directly. In most cases where you might want to return a trait, you can instead use the concrete type that implements the trait as the return value of the function. However, you can’t do that with closures because they don’t have a concrete type that is returnable; 
	
	\inputminted{rust}{./code/fn2.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Macros(like \mintinline{rust}|println!|)}
	\begin{itemize}
		\item Fundamentally, macros are \textbf{a way of writing code that writes other code}, which is known as \textbf{metaprogramming}. 
		\item Macros can take a variable number of parameters: we can call \mintinline{rust}|println!("hello")| with one argument or \mintinline{rust}|println!("hello {}", name)| with two arguments. 
		\item The term macro refers to a family of features in Rust: 
		\begin{itemize}
			\item \textbf{Declarative macros} with \mintinline{rust}|macro_rules!|  and 
			\item 	Three kinds of \textbf{procedural macros}:
			\begin{itemize}
				\item \textbf{Custom \mintinline{rust}|#[derive]| macros} that specify code added with the derive attribute used on \mintinline{rust}|structs| and \mintinline{rust}|enums|
				\item 	\textbf{Attribute-like} macros that define custom attributes usable on any item
				\item 	\textbf{Function-like macros} that look like function calls but operate on the tokens specified as their argument
			\end{itemize}
		\end{itemize}
	\end{itemize}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Declarative Macros with \mintinline{rust}|macro_rules!| for General Metaprogramming}

The most widely used form of macros in Rust is the declarative macro. These are also sometimes referred to as “\textbf{macros by example},” “\mintinline{rust}|macro_rules!| macros,” or just plain “\textbf{macros}.” At their core, declarative macros allow you to write something similar to a Rust \textbf{match expression}.

	\inputminted{shell}{./code/macro2.rs}
	
	There must be at least one rule, and you can omit the semicolon after the last rule. You can use brackets([]), parentheses(()) or braces({}).

\end{frame}

\begin{frame}[fragile]
	\frametitle{Declarative Macros Example}
	\inputminted[fontsize=\scriptsize]{shell}{./code/macro1.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Declarative Macros Example(2)}
	First, we use a set of parentheses to encompass the whole pattern. We use a dollar sign \mintinline{shell}|($)| to declare a variable in the macro system that will contain the Rust code matching the pattern. The dollar sign makes it clear this is a macro variable as opposed to a regular Rust variable. Next comes a set of parentheses that captures values that match the pattern within the parentheses for use in the replacement code. Within \mintinline{shell}|$()| is \mintinline{shell}|$x:expr|, which matches any Rust expression and gives the expression the name \mintinline{shell}|$x|.
	The comma following \mintinline{shell}|$()| indicates that a literal comma separator character could optionally appear after the code that matches the code in \mintinline{shell}|$()|. The \mintinline{rust}|*| specifies that the pattern matches zero or more of whatever precedes the \mintinline{rust}|*|.
	When we call this macro with \mintinline{rust}|my_vec![1, 2, 3];|, the \mintinline{shell}|$x| pattern matches three times with the three expressions 1, 2, and 3.
\end{frame}

\begin{frame}[fragile]
	\frametitle{Declarative Macros Example(3)}
\inputminted{rust}{./code/macro3.rs}

For more examples see:  \href{https://veykril.github.io/tlborm/decl-macros/macros-methodical.html}{“\textbf{\underline{The Little Book of Rust Macros}}”}

\end{frame}


\begin{frame}[fragile]
	\frametitle{How to Write a Custom derive Macro}
\begin{itemize}
	\item 	\textit{\textbf{Procedural macro}}, which acts more like a function (and is a type of procedure). Procedural macros accept some code as an input, operate on that code, and produce some code as an output rather than matching against patterns and replacing the code with other code as declarative macros do.
	\item Let’s create a crate named \mintinline{rust}|hello_macro| that defines a trait named \mintinline{rust}|HelloMacro| with one associated function named \mintinline{rust}|hello_macro|. Rather than making our users implement the \mintinline{rust}|HelloMacro| trait for each of their types, we’ll provide a procedural macro so users can annotate their type with \mintinline{rust}|#[derive(HelloMacro)]| to get a default implementation of the \mintinline{rust}|hello_macro function|.
	\inputminted[fontsize=\scriptsize]{rust}{./code/macro4.rs}
\end{itemize}
\end{frame}


\begin{frame}[fragile]
	\frametitle{How to Write a Custom derive Macro(2)}
		\inputminted[fontsize=\scriptsize]{rust}{./code/macro5.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{How to Write a Custom derive Macro(2)}
	\begin{itemize}
		\item We need functionality from the syn and quote crates.
		\item 	The \mintinline{rust}|syn| crate parses Rust code from a string into a data structure that we can perform operations on. 
		\item 	The \mintinline{rust}|quote| crate turns syn data structures back into Rust code.
		\item The \mintinline{rust}|hello_macro_derive| function first converts the input from a \mintinline{rust}|TokenStream| to a data structure that we can then interpret and perform operations on. This is where syn comes into play. The parse function in syn takes a \mintinline{rust}|TokenStream| and returns a \mintinline{rust}|DeriveInput struct| representing the parsed Rust code.
	\end{itemize}

\end{frame}

\begin{frame}[fragile]
	\frametitle{How to Write a Custom derive Macro(2)}
	
	\inputminted{rust}{./code/macro6.rs}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Attribute-like macros}
	
	\inputminted{rust}{./code/macro7.rs}
	
	Here, we have two parameters of type \mintinline{rust}|TokenStream|. The first is for the contents of the attribute: the \mintinline{rust}|GET|, \mintinline{rust}|"/"| part. The second is the body of the item the attribute is attached to: in this case, \mintinline{rust}|fn index() {}| and the rest of the function’s body.
	
\end{frame}


\begin{frame}[fragile]
	\frametitle{Function-like macros}
	
	\inputminted{rust}{./code/macro8.rs}
\end{frame}


\section{Multithread Web Server}
\begin{frame}[fragile]
	\frametitle{Building a Single-Threaded Web Server}
	\begin{itemize}
		\item The two main protocols involved in \textbf{web servers} are \textbf{Hypertext Transfer Protocol (HTTP)} and \textbf{Transmission Control Protocol (TCP)}. Both protocols are \textbf{request-response protocols}, meaning a client initiates requests and a server listens to the requests and provides a response to the client. The contents of those requests and responses are defined by the protocols.
		\item 	TCP is the lower-level protocol that describes the details of how information gets from one server to another but doesn’t specify what that information is. HTTP builds on top of TCP by defining the contents of the requests and responses.
	\end{itemize}
	
\end{frame}


\begin{frame}[fragile]
	\frametitle{Building a Single-Threaded Web Server (2)}
	\inputminted[fontsize=\scriptsize]{rust}{./code/http1.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Building a Single-Threaded Web Server (3)}
	\inputminted[fontsize=\scriptsize]{shell}{./code/http1.shell}
\end{frame}



\begin{frame}[fragile]
	\frametitle{Spawning a Thread for Each Request}
	\inputminted{rust}{./code/http2.rs}
	
	This will eventually overwhelm the system because you’d be making new threads without any limit
\end{frame}


\begin{frame}[fragile]
	\frametitle{Improving Throughput with a Thread Pool}
	A thread pool is a group of spawned threads that are waiting and ready to handle a task. When the program receives a new task, it assigns one of the threads in the pool to the task, and that thread will process the task. The remaining threads in the pool are available to handle any other tasks that come in while the first thread is processing. When the first thread is done processing its task, it’s returned to the pool of idle threads, ready to handle a new task. A thread pool allows you to process connections concurrently, increasing the throughput of your server.
\end{frame}


\begin{frame}[fragile]
	\frametitle{Creating a Finite Number of Threads}
	\inputminted{rust}{./code/http3.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Creating a Finite Number of Threads(2)}
	\inputminted{rust}{./code/http4.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Creating a Finite Number of Threads(3)}
	\inputminted[fontsize=\scriptsize]{rust}{./code/http5.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{A Worker Struct Responsible for Sending Code from the ThreadPool to a Thread}
	\inputminted[fontsize=\scriptsize]{rust}{./code/http6.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{A Worker Struct Responsible for Sending Code from the ThreadPool to a Thread(2)}
	\inputminted[fontsize=\scriptsize]{rust}{./code/http7.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Sending Requests to Threads via Channels}
	\inputminted[fontsize=\fontsize{8.5}{8.5}]{rust}{./code/http8.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Sending Requests to Threads via Channels}
	\inputminted[fontsize=\fontsize{8.5}{8.5}]{rust}{./code/http8.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Sending Requests to Threads via Channels(2)}
	\inputminted[fontsize=\fontsize{8.5}{8.5}]{rust}{./code/http9.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Sending Requests to Threads via Channels(3)}
	\inputminted[fontsize=\fontsize{8.5}{8.5}]{rust}{./code/http10.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Implementing the execute Method}
	\inputminted[fontsize=\scriptsize]{rust}{./code/http11.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Implementing the execute Method(2)}
	\inputminted[fontsize=\scriptsize]{rust}{./code/http12.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Call Mutex lock in While let}
	You might be wondering why we didn’t write the worker thread code as below: 
	
	\inputminted[fontsize=\scriptsize]{rust}{./code/http13.rs}
	
	\textbf{Why}?
\end{frame}

\begin{frame}[fragile]
	\frametitle{Call Mutex lock in While let (2)}
	
	\scriptsize
	\begin{itemize}
		\item This code compiles and runs but doesn’t result in the desired threading behavior: \textbf{a slow request will still cause other requests to wait to be processed}. 
		\item 	The reason is somewhat subtle: the  \mintinline{rust}|Mutex| struct has no public unlock method because the ownership of the lock is based on the lifetime of the \mintinline{rust}|MutexGuard<T>| within the \mintinline{rust}|LockResult<MutexGuard<T>>| that the lock method returns. At compile time, the borrow checker can then enforce the rule that a resource guarded by a \mintinline{rust}|Mutex| cannot be accessed unless we hold the lock. However, this implementation can also result in \textbf{the lock being held longer }than intended if we aren’t mindful of the lifetime of the \mintinline{rust}|MutexGuard<T>|.
		\item 	The code uses \mintinline{rust}|let job = receiver.lock().unwrap().recv().unwrap()|; works because with let, any temporary values used in the expression on the right hand side of the equals sign are \textbf{immediately dropped when the let statement ends}. However, while let (and if let and match) does not drop temporary values until the end of the associated block. In this case, the lock remains held for the duration of the call to job(), meaning other workers cannot receive jobs.
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Graceful Shutdown and Cleanup, Implementing the Drop Trait on ThreadPool}
	\inputminted[fontsize=\scriptsize]{rust}{./code/http14.rs}
	
	\scriptsize
	The error tells us we can’t call join because we only have a mutable borrow of each worker and join takes ownership of its argument. To solve this issue, we need to move the thread out of the Worker instance that owns thread so join can consume the thread. If Worker holds an \mintinline{rust}|Option<thread::JoinHandle<()>>| instead, we can call the \mintinline{rust}|take| method on the Option to move the value out of the Some variant and leave a None variant in its place. In other words, a Worker that is running will have a Some variant in thread, and when we want to clean up a Worker, we’ll replace Some with None so the Worker doesn’t have a thread to run.
	
\end{frame}


\begin{frame}[fragile]
	\frametitle{Graceful Shutdown and Cleanup, Implementing the Drop Trait on ThreadPool(2)}
	\inputminted{rust}{./code/http15.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Graceful Shutdown and Cleanup, Implementing the Drop Trait on ThreadPool(3)}
	\inputminted{rust}{./code/http16.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Signaling to the Threads to Stop Listening for Jobs}
	\begin{itemize}
		\item The key is the logic in the closures run by the threads of the Worker instances: at the moment, we call join, but that \textbf{won’t shut down the threads} because they \textbf{loop forever} looking for jobs.
		\item 	\textbf{To fix this problem}, we’ll need a \textbf{change} in \textbf{the ThreadPool drop implementation} and then a \textbf{change in the Worker loop}.
	\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Change in the ThreadPool drop implementation}
	\inputminted[fontsize=\fontsize{8}{8}]{rust}{./code/http17.rs}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Change in the ThreadPool drop implementation(2)}
	\inputminted{rust}{./code/http18.rs}
\end{frame}


\begin{frame}[fragile]
	\frametitle{Change in the Worker loop}
	\inputminted{rust}{./code/http19.rs}
\end{frame}

\section{Tokio}

\section*{Acknowledgement}
\begin{frame}
	\Huge{\centerline{Thank you!}}
\end{frame}

\end{document}

\begin{comment}
\begin{frame}[fragile]
	\frametitle{title}
\end{frame}

\begin{columns}
	\column{0.5\textwidth}
	\tableofcontents[sections = 1-10]
	\column{0.5\textwidth}
	\tableofcontents[sections = 11-20]
\end{columns}
\end{comment}