You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
\frametitle{Shortcuts for Panic on Error: unwrap and expect }
1507
1507
\scriptsize
1508
-
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.
1509
-
1508
+
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.
We use \mintinline{rust}|expect| in the same way as unwrap: to return the file handle or call the panic! macro.
@@ -1535,10 +1535,10 @@ \section{Error Handling}
1535
1535
1536
1536
\begin{frame}[fragile]
1537
1537
\frametitle{Where The \mintinline{rust}|?| Operator Can Be Used}
1538
-
\begin{itemize}
1539
-
\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.
1540
-
\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|.
1541
-
\end{itemize}
1538
+
\begin{itemize}
1539
+
\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.
1540
+
\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|.
1541
+
\end{itemize}
1542
1542
1543
1543
\inputminted{rust}{./code/result11.rs}
1544
1544
\end{frame}
@@ -1556,18 +1556,18 @@ \section{Generic Types, Traits, and Lifetimes}
1556
1556
\begin{frame}[fragile]
1557
1557
\frametitle{Generic Data Types}
1558
1558
We use generics to create definitions for items like function signatures or structs, which we can then use with many different concrete data types.
@@ -1594,13 +1594,13 @@ \section{Generic Types, Traits, and Lifetimes}
1594
1594
1595
1595
\begin{frame}[fragile]
1596
1596
\frametitle{Monomorphization}
1597
-
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.
1598
-
1597
+
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.
@@ -1698,20 +1698,20 @@ \section{Generic Types, Traits, and Lifetimes}
1698
1698
1699
1699
\begin{frame}[fragile]
1700
1700
\frametitle{Lifetime Annotation Syntax}
1701
-
\begin{itemize}
1702
-
\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.
1703
-
\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.
1704
-
1705
-
\inputminted{rust}{./code/lifetime3.rs}
1706
-
\end{itemize}
1701
+
\begin{itemize}
1702
+
\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.
1703
+
\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.
1704
+
1705
+
\inputminted{rust}{./code/lifetime3.rs}
1706
+
\end{itemize}
1707
1707
\end{frame}
1708
1708
1709
1709
1710
1710
\begin{frame}[fragile]
1711
1711
\frametitle{Lifetime Annotations in Function Signatures}
1712
1712
\inputminted{rust}{./code/lifetime4.rs}
1713
1713
1714
-
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.
1714
+
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.
1715
1715
\end{frame}
1716
1716
1717
1717
@@ -1723,11 +1723,11 @@ \section{Generic Types, Traits, and Lifetimes}
1723
1723
1724
1724
\end{frame}
1725
1725
1726
-
\begin{frame}[fragile]
1727
-
\frametitle{Lifetime Annotations in Function Signatures (3)}
1728
-
\inputminted{shell}{./code/lifetime5.shell}
1729
-
1730
-
\end{frame}
1726
+
\begin{frame}[fragile]
1727
+
\frametitle{Lifetime Annotations in Function Signatures (3)}
1728
+
\inputminted{shell}{./code/lifetime5.shell}
1729
+
1730
+
\end{frame}
1731
1731
1732
1732
\begin{frame}[fragile]
1733
1733
\frametitle{Lifetime Annotations in Struct Definitions}
@@ -1785,7 +1785,7 @@ \section{Generic Types, Traits, and Lifetimes}
1785
1785
1786
1786
\begin{frame}[fragile]
1787
1787
\frametitle{Generic Type Parameters, Trait Bounds, and Lifetimes Together}
\item We can pass the name of any test function to \mintinline{shell}|cargo test| to run only that test.
1865
1865
\item We can specify part of a test name, and any test whose name matches that value will be run.
1866
1866
\end{itemize}
1867
-
\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|.
\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|.
\item The Rust community thinks about tests in terms of two main categories: \textbf{unit tests} and \textbf{integration tests}.
1878
-
\begin{itemize}
1879
-
\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)]|.
1880
-
\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}.
1878
+
\begin{itemize}
1879
+
\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)]|.
1880
+
\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}.
1881
+
\end{itemize}
1881
1882
\end{itemize}
1882
-
\end{itemize}
1883
1883
\end{frame}
1884
1884
1885
1885
1886
1886
\begin{frame}[fragile]
1887
1887
\frametitle{Integration test}
1888
1888
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.
\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.
1940
+
\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|
1941
+
\end{itemize}
1942
+
1931
1943
\end{frame}
1932
1944
1933
-
\section{An I/O Project: Building a Command Line Program}
1945
+
\begin{frame}[fragile]
1946
+
\frametitle{minigrep - Reading the Argument Values}
0 commit comments